Site links are used to connect two or more sites together for the purpose of replication. When you install Active Directory in a new forest, a new site link called the DEFAULTIPSITELINK is created. As you add additional sites to the forest, these sites are included in the default site link unless you have configured other site links. If all of the network connections between sites are the same speed and priority, the default configuration can work. In this case, the intersite replication configuration for all sites will have the same properties. If you were to change these properties, the changes would affect the replication topology for all sites. By creating additional site links, you can configure different replication properties when the network connections between sites have different speeds and priorities.
Creating additional site links helps the designated Inter-Site Topology Generator (ISTG) for a site to prioritize the site links and determine when a site link should be used. It doesn't, however, change the way intersite replication works. Replication traffic between sites is always sent from a bridgehead server in one site to a bridgehead server in another site. Although it is the job of the ISTG to generate the intersite replication topology and designate bridgehead servers, you can manually designate bridgehead servers as well. Once you've established site links and designated bridgehead servers as necessary, you might want to change the way replication between sites is handled. For example, you might want to disable compression or enable notification so changes can be replicated more quickly between sites.
Following this, the most common administrative tasks related to site links involve the following:
Creating site links
Configuring site link bridges
Determining the ISTG
Configuring site bridgehead servers
Setting site link replication options
Before looking at these administrative tasks, however, let's first look at the available replication transports.
When you create a site link, you will have to select a replication transport protocol. Two replication transports are available: IP and Simple Mail Transfer Protocol (SMTP). All replication connections within sites are synchronous and use RPC over IP. In this configuration, domain controllers establish an RPC over IP connection with a single replication partner at a time and replicate Active Directory changes. By default, the remote procedure call (RPC) connection uses dynamic port mapping. During replication, a replication client establishes a connection to a server on the RPC endpoint mapper port 135 and determines which port is to be used for replication on the server. Any additional replication traffic is sent over the ports defined in Table 35-1. When RPC over IP is used for intersite replication, these same ports are used. If there are firewalls between the sites, the appropriate ports on the firewalls must be opened to allow replication to occur.
Because RPC over IP is synchronous, both replication partners must be available at the time the connection is established. This is important because of the transitive nature of site links. For example, if Site 1 has a link to Site 2, and Site 2 has a link to Site 3, there is an automatic bridge between Site 1 and Site 3 that allows Site 1 to replicate traffic directly to Site 3. Because of this, you must carefully configure site link schedules so that all potential RPC over IP replication partners are available as necessary—more on this in a moment.
Replication between sites can also be configured to use SMTP. By using SMTP as the transport, all replication traffic is converted to e-mail messages that are sent between the sites. Because SMTP replication is asynchronous, it can be a good choice when you do not have a permanent connection between sites or when you have unreliable connections between sites. It is also a good choice when you have to replicate between locations over the public Internet.
Before you use SMTP as the replication protocol, there are several important considerations. First, SMTP can be used only to replicate information between domain controllers in different domains because the domain directory partition cannot be replicated using SMTP—only the configuration, schema, and global catalog directory partitions can be replicated. Second, SMTP messages are digitally signed and encrypted to ensure that replication traffic is secure even if replication traffic is routed over the public Internet. All domain controllers that will use SMTP for replication require additional components to create, digitally sign, and then encrypt e-mail messages. Specifically, you must install the SMTP Service subcomponent of Microsoft Internet Information Services (IIS) on each domain controller and you must install a Microsoft certificate authority (CA) in your organization. The certificates from the CA are used to digitally sign and encrypt the SMTP messages sent between the sites.
Tip
Configure replication through firewalls
If you plan to use SMTP for replication, you must open port 25 on the firewall between sites. Port 25 is the default port used for SMTP. Although SMTP has definite security advantages over standard IP, you can encrypt RPC communications between domain controllers using IP Security (IPSec) and then open the appropriate ports on your firewalls for RPC over IP. Encrypting the RPC traffic between domain controllers would then be a viable alternative for replication over the public Internet when you have a dedicated connection between sites.
After you create the sites that your organization needs, you can create site links between those sites to better manage intersite replication. Each site link must have at least two sites associated with it. These sites establish the endpoints or transit points for the link. For example, if you create a site link and add Portland-First-Site and LA-First-Site to the link, the Portland and LA sites are the endpoints for the link and the ISTG will use the link to create the connection objects that are required to replicate traffic between these sites.
Before you create a site link, you should determine the transport that you want to use as discussed previously in the section entitled "Understanding IP and SMTP Replication Transports" earlier in this chapter. You should also consider the following:
Link cost The cost for a site link determines the relative priority of the link in relationship to other site links that might be available. If there are multiple possible routes to a site, the route with the lowest link cost is used first. In the event a primary link fails, a secondary link can be used. Typically, the link cost reflects the bandwidth available for a specific connection. It can also reflect the actual cost of sending traffic over a particular link if the organization has to pay a fee based on bandwidth usage.
Replication schedule The replication schedule determines the times during the day that the site link is available for replication. By default, replication is allowed 24 hours a day. If you have a limited-bandwidth connection or you want user traffic to have priority at certain times of the day, you might want to configure a different availability schedule.
Replication interval The replication interval determines the intervals at which the bridgehead servers in each site check to see if there are directory updates available. By default, the interval is set to 180 minutes. Following this, if the replication schedule is configured to allow replication from 7 P.M. to 7 A.M. each day, the bridgehead servers will check for updates at 7 P.M., 10 P.M., 1 A.M., 4 A.M., and 7 A.M. daily.
You can create a site link between two or more sites by completing the following steps:
Start Active Directory Sites and Services by clicking Start, Programs or All Programs, Administrative Tools, and Active Directory Sites And Services. If your organization has multiple forests, you might need to connect to another forest. To do this, right-click the Active Directory Sites And Services node in the console tree, and then select Connect To Forest. In the Connect To Forest dialog box, type the name of the root domain in the forest to which you want to connect, and then click OK.
Expand the Sites container, and then expand the Inter-Site Transports container. Right-click the container for the transport protocol you want to use, either IP or SMTP, and select New Site Link. This displays the New Object—Site Link dialog box, as shown in Figure 39-3.
In the New Object—Site Link dialog box, type a descriptive name for the site link. The site name serves as a point of reference for administrators and should clearly depict the sites the link connects.
In the Sites Not In This Site Link list, select a site that should be included in the link, and then click Add to add the site to the Sites In This Link list. Repeat this process for each site you want to add to the link. The link must include at least two sites.
Click OK to close the New Object—Site Link dialog box.
In Active Directory Sites And Services, the site link is added to the appropriate transport folder (IP or SMTP). Select the transport in the console tree, and then doubleclick the site link in the right pane. This displays the Link Properties dialog box, as shown in Figure 39-4.
Use the Cost combo box to set the relative cost of the link. The default cost is 100. For pointers on determining what cost to use, see the sections entitled "Mapping Network Infrastructure" and "Designing the Intersite Replication Topology".
Use the Replicate Every combo box to set the replication interval. The default interval is 180 minutes.
By default, the site link is available for replication 24 hours a day. To set a different schedule, click Change Schedule, and then use the Schedule For dialog box to set the desired replication schedule. When you are finished, click OK.
Click OK to close the site link's Properties dialog box.
Active Directory Site Administration
Inside Out: The transitive nature of site links
Site links are transitive and follow the three hops rules as discussed in Chapter 35. This means that if Site 1 is linked to Site 2, Site 2 is linked to Site 3, and Site 3 is linked to Site 4, the domain controllers in Site 1 can replicate with Site 2, Site 3, and Site 4. Because of the transitive nature of site links, site link replication schedules and intervals for each site link are combined to determine the effective replication window and interval. To see the impact of combining replication schedules and intervals, consider the following examples:
Site 1 to Site 2 link has a replication schedule of 7 P.M. to 7 A.M. and an interval of 60 minutes.
Site 2 to Site 3 link has a replication schedule of 9 P.M. to 5 A.M. and an interval of 60 minutes.
Site 3 to Site 4 link has a replication schedule of 1 P.M. to 3 A.M. and an interval of 180 minutes.
Because of the overlapping windows and intervals, replication between Site 1 and Site 2 could occur every 60 minutes from 7 P.M. to 7 A.M. Replication between Site 1 and Site 3 could occur every 60 minutes from 9 P.M. to 5 A.M. Replication between Site 1 and Site 4 could occur every 180 minutes from 9 P.M. to 3 A.M. This occurs because the replication availability window must overlap for replication to occur using transitive links.
If the site replication schedules do not overlap, replication is still possible between multiple sites. To see how replication would work if schedules do not overlap, consider the following example:
Site 1 to Site 2 link has a replication schedule of 11 P.M. to 3 A.M. and an interval of 60 minutes.
Site 2 to Site 3 link has a replication schedule of 6 P.M. to 9 P.M. and an interval of 60 minutes.
Site 3 to Site 4 link has a replication schedule of 1 A.M. to 5 A.M. and an interval of 180 minutes.
Assuming there are no alternate links between the sites, replication between Site 1 and Site 2 could occur every 60 minutes from 11 P.M. to 3 A.M. Site 1 would not be able to replicate with Site 3 and Site 4, however. Instead, Site 2 would replicate changes to Site 3 every 60 minutes from 6 P.M. to 9 P.M. daily. Site 3 would in turn replicate changes to Site 4 every 180 minutes from 1 A.M. to 5 A.M. daily. In this configuration, there is significant replication latency (delay). Changes made at 5 P.M. in Site 1 would not be replicated to Site 2 until 11 P.M. The following day the changes would be replicated to Site 3 at 6 P.M., and then at 1 A.M. on the third day the changes would be replicated to Site 4.
Be default, all site links are transitive, which allows Active Directory to automatically configure site link bridges between sites. When a site is bridged, any two domain controllers can make a connection across any consecutive series of links as long as the site links are all using the same transport. The site link bridge cost is the sum of all the links included in the bridge.
A significant advantage of automatically created site link bridges is that fault tolerance is built in whenever there are multiple possible routes between sites. Another significant advantage is that Active Directory automatically manages the site link bridges and the ISTG monitors for changes and reconfigures the replication topology accordingly—and all without any administrator involvement required. Site link bridges are discussed in more detail in the section entitled "Considering the Impact of Site Link Bridging".
You can enable or disable site link bridges on a per-transport basis. By default, both the IP and SMTP transports have site link bridging enabled. If you disable site link bridging, Active Directory will no longer manage site link bridges for the transport. You must then create and manage all site link bridges for that transport. Any sites you add to a site link bridge are considered to be transitive with each other. Site links that are not included in the site link bridge are not transitive.
To see how this would work, consider the previous example in which Site 1 is linked to Site 2, Site 2 is linked to Site 3, and Site 3 is linked to Site 4. If you disable site link bridging and then create a site link bridge that includes Site 1, Site 2, and Site 3, only those sites would have a transitive site link. Site 4 would be excluded. This would mean Site 1 could replicate changes to Site 2 and Site 1 could replicate changes to Site 3. Site 1 could not, however, replicate changes to Site 4. Only Site 3 would replicate changes to Site 4. This would occur because adjacent sites can always replicate changes with each other.
Note
One reason to create site link bridges manually is to reduce the processing overhead on the designated ISTGs in each site. When you disable transitive links, the ISTGs no longer have to create and manage the site link bridges, and this reduces the number of computations required to create the intersite replication topology.
To turn off transitive site links and manually configure site link bridges, follow these steps:
Start Active Directory Sites and Services by clicking Start, Programs or All Programs, Administrative Tools, and Active Directory Sites And Services.
Expand the Sites container, and then expand the Inter-Site Transports container. Right-click the container for the transport protocol you want to work with, either IP or SMTP, and then select Properties. This displays a Properties dialog box (see Figure 39-5).
Clear Bridge All Site Links, and then click OK. If you later want to enable transitive links and have Active Directory ignore the site link bridges you've created, you can select Bridge All Site Links.
Once you've disabled transitive links, you can manually create a site link bridge between two or more sites by completing the following steps:
In Active Directory Sites and Services, expand the Sites container, and then expand the Inter-Site Transports container. Right-click the container for the transport protocol you want to use, either IP or SMTP, and then select New Site Link Bridge. This displays the New Object—Site Link Bridge dialog box, as shown in Figure 39-6.
In the New Object—Site Link Bridge dialog box, type a descriptive name for the site link bridge. This name serves as a point of reference for administrators and should clearly depict all the site links that are a part of the bridge.
In the Site Links Not In This Site Link Bridge list, select a site link that should be included in the bridge and then click Add to add the site link to the Site Links In This Site Link Bridge list. Repeat this process for each site link you want to add to the bridge. The bridge must include at least two site links.
Click OK to close the New Object—Site Link Bridge dialog box.
Each site has an ISTG that is responsible for generating the intersite replication topology. As your organization grows and you add domain controllers and sites, the load on the ISTG can grow substantially because each addition means the ISTG must perform additional calculations to determine and maintain the optimal topology. When it is calculating the replication topology, its processor typically will reach 100 percent utilization. As the topology becomes more and more complex, the process will stay at maximum utilization longer and longer.
Because there is the potential for the ISTG to get overloaded, you should monitor the designated ISTG in a site more closely than other domain controllers. You can determine the ISTG by completing the following steps:
In Active Directory Sites and Services, expand the Sites container, and then select the site whose ISTG you want to locate in the console tree.
In the Details pane, double-click NTDS Site Settings.
In the NTDS Site Settings dialog box, the current ISTG is listed in the Inter-Site Topology Generator panel, as shown in Figure 39-7.
Replication between sites is performed by bridgehead servers in each site. A bridgehead server is a domain controller designated by the ISTG to perform intersite replication. Bridgehead servers are discussed in detail in the sections entitled "Intersite Replication Essentials" and "Replication Rings and Directory Partitions".
As with the ISTG role, operating as a bridgehead server can add a significant load to a domain controller. This load increases with the number and frequency of replication changes. Because of this, the designated bridgehead servers should also be closely monitored to make sure they don't become overloaded.
Tip
Determine bridgehead servers
You can determine the current bridgehead servers throughout the enterprise using Replication Monitor, which I discuss in the section entitled "Monitoring and Troubleshooting Replication" later in this chapter. If you want to examine the bridgehead servers in the current site, type repadmin /bridgeheads at the command prompt.
In situations in which you have domain controllers that are already overloaded or not equipped to possibly handle the additional load of being a bridgehead server, you might want to control which domain controllers operate as bridgehead servers. You do this by designating preferred bridgehead servers in a site.
There are several important considerations for designating bridgehead servers. First, once you designate a preferred bridgehead server, the ISTG will use only the preferred bridgehead server for intersite replication. This means if the domain controller acting as the bridgehead server goes offline or is unable to replicate for any reason, intersite replication will stop until the server is again available for replication or you change the preferred bridgehead server configuration options. In the latter case, you would need to do one of the following:
Remove the server as a preferred bridgehead server and then specify a different preferred bridgehead server
Remove the server as a preferred bridgehead server and then allow the ISTG to select the bridgehead servers that should be used
Because you can designate multiple preferred bridgehead servers, you can prevent this situation simply by specifying more than one preferred bridgehead server. When there are multiple preferred bridgehead servers, the ISTG will choose one of the servers you've designated as the preferred bridgehead server. If this server fails, it would then choose another server from the list of preferred bridgehead servers.
An additional consideration to make when designating preferred bridgehead servers is that you must configure a bridgehead server for each partition that needs to be replicated. This means you must configure at least one domain controller with a replica of each directory partition as a bridgehead server. If you don't do this, replication of the partition will fail and the ISTG will log an event in the Directory Services event log detailing the failure. Consider the example shown in Figure 39-8.
Here, the Denver-Site and the NY-Site are part of the same domain, ThePhone-Company.com. Each site has a global catalog and a DNS server that is integrated with Active Directory. In this configuration, the bridgehead servers must replicate the following directory partitions: domain, configuration, schema, global catalog, and DNS (for the Domain Name System). If you designated DC3 and DC5 as the preferred bridgehead servers, only the domain, configuration, schema directory partitions would be replicated. This means replication for the global catalog and the DNS partition would fail and the ISTG would log an event in the Directory Services event log specifying the reason for the failure. On the other hand, if you designated DC1 and DC2 as the preferred bridgehead servers for the Denver site and DC4 and DC6 as the preferred bridgehead servers for the NY site, all the directory partitions would be replicated.
To configure a domain controller as a preferred bridgehead server, complete the following steps:
Start Active Directory Sites and Services by clicking Start, Programs or All Programs, Administrative Tools, and Active Directory Sites And Services.
Domains controllers associated with a site are listed in the site's Servers node. To locate the domain controller that you want to work with, expand the site node, and then expand the related Servers node.
Right-click the server you want to designate as a preferred bridgehead, and then select Properties.
In the Properties dialog box, shown in Figure 39-9, you have the option of configuring the server as a preferred bridgehead server for either IP or SMTP. Select the appropriate transport in the Transports Available For list, and then click Add. If you later want the server to stop being a preferred bridgehead, select the transport in the This Server Is A Preferred Bridgehead Server list, and then click Remove.
Click OK.
Once you've configured a site link, you might want to change the site's configuration options, including whether replication compression and notification are enabled or disabled. You do this by editing the Options attribute on either the site link object or the connection object related to the site link you want to modify. Only members of the Enterprise Admins group can change these options.
If you are a member of the Enterprise Admins groups, you can manage the site option attributes for compression and notification using the ADSI Edit snap-in for the Microsoft Management Console (MMC). When you start this snap-in, you must make a connection to a replica of the Configuration container. Because every domain controller has a writeable copy of the configuration data, any domain controller to which you are connected when you start ADSI Edit will suffice.
You can access and use ADSI Edit to configure the site link object's Options attribute by following these steps:
Open a blank MMC in Author mode. Click Start, select Run, type mmc in the Open field, and then click OK.
Choose Add/Remove Snap-in from the File menu in the main window. Choose Add, which displays the Add Standalone Snap-In dialog box.
Click ADSI Edit, and then choose Add. The ADSI Edit snap-in is added to the list of snap-ins in the Add/Remove Snap-In dialog. Click Close, and then click OK.
When you first start ADSI Edit, it won't have any connections to containers within Active Directory. Because of this, you must add the connections to the Configuration container. Right-click the ADSI Edit node in the left pane, and then click Connect to. This displays the Connections Settings dialog box, as shown in Figure 39-10.
In the Connection Point panel, choose Select A Well Known Naming Context, and then select Configuration. This specifies that you want to make a connection to the Configuration Container in Active Directory. Click OK.
After you add the snap-in to a custom console and connect to the Configuration container in Active Directory, you can edit site link objects. In ADSI Edit, expand the ADSI Edit node, expand Configuration, and then expand the configuration container for the forest; it is named with its distinguished name, as shown in Figure 39-11.
Next expand CN=Sites, CN=Inter-Site Transports, and then select the container for the appropriate transport type, either CN=IP for the link's IP transport or CN=SMTP for the link's SMTP transport.
In the details pane, right-click the site link you want to work with, and select Properties. This displays the link Properties dialog box.
Scroll through the list of attributes until you find the Options attribute. When you find this attribute, click it to select it, and then click Edit.
In the Integer Attribute Editor dialog box, you can now do the following:
Type 1 to enable notification for intersite replication. This means the bridgehead servers on either side of the link will no longer use compression. Use this option only when you have sufficient bandwidth for a site connection and are concerned about high processor utilization on the affected bridgehead servers.
Type 4 to turn off compression for intersite replication. This means the bridgehead servers on either side of the link can notify each other that changes have occurred. This allows the bridgehead server receiving the notification to pull the changes across the site link and thereby get more frequent updates.
Type 5 to set both options. This means compression will be turned off and notification for intersite replication will be enabled.
Click Clear to reset the Options attribute to its default value <not set>. When Options is not set, notification for intersite replication is disabled and compression is turned on.
Click OK twice.
