This chapter is from the book
This chapter is from the book
This chapter is from the book
Active Directory Site Topology
- Objective
- Implement an Active Directory site topology
Recall from Chapter 1 the nature of sites in Active Directory. A site is a grouping of computers and other objects that is connected by high-speed LAN connections and contains one or more Internet Protocol (IP) subnets. A site consists of one or more IP subnets that share a fast, reliable connection such as a local area network (LAN) connection. Because wide area network (WAN) connections are slower and might not be continuously available, network segments located across a WAN should be configured as separate sites. Configuring network segments this way is especially important if your company needs to pay for the WAN link by the number of minutes it is active or the amount of data sent across it.
When planning sites, you should assess the needs of various offices and divisions within your company, as well as the speed and utilization of the links between the offices. When assessing the needs, you should do the following:
- Assess the physical environment—You should look at the locations in which your company is conducting business and the nature of the internal and external network connections. Be sure to check factors such as the placement of domain controllers and the need to access resources at different offices. Even if locations are on different subnets, if they are connected by a reliable, fast, high-bandwidth link such as a T3 line, you might be able to include them in a single site.
- Assess the need for frequent replication versus bandwidth usage—If a location needs the most recent Active Directory information and is connected with a fast link, it does not need to be in a different site.
- Identify the types of physical links between sites—The type, speed, and utilization of the connection between locations are important factors. Active Directory provides the concept of site link objects that can be used to determine the replication schedule between sites that it links. A cost value also can be associated with it; this value determines when and how often replication can occur.
- Configure site link bridges—The site link bridge is an Active Directory mechanism that groups sites together to facilitate optimized intersite replication. We discuss site link bridges further later in this chapter.
Creating Sites
When you first install Active Directory, all domain controllers are located in a single site with the rather ostentatious name of Default-First-Site-Name. If you want, you can rename this site in the same way you would rename a file or folder. After you have assessed the need for additional sites, creating a new site is simple. See Step by Step 3.15.
Step by Step 3.15 Creating a New Site
- Click Start, Administrative Tools, Active Directory Sites and Services.
- Right-click the Sites folder and choose New Site.
- In the New Object—Site dialog box, type the name of the site. Select a site link object from the list provided, as shown in Figure 3.39, and then click OK.
Figure 3.39 You use the New Object—Site dialog box to create a new site.
- You receive a message box listing other tasks you should perform, as shown in Figure 3.40. Click OK.
Figure 3.40 Windows reminds you of several tasks to be completed after creating a site.
- The site you created appears in the console tree of Active Directory Sites and Services, and several default containers appear in the details pane.
)
)
Configuring Sites
You should perform several tasks after you have created a site. These tasks include adding domain controllers to a site, specifying licensing servers, and configuring site boundaries. We describe these tasks in the sections that follow.
Adding Domain Controllers
The first task you should complete is adding domain controllers to the site. Follow Step by Step 3.16 to perform the first task: adding a domain controller to the site you just created.
Step by Step 3.16 Adding Domain Controllers to a Site
- In Active Directory Sites and Services, expand the site containing the domain controller you want to move to reveal a Servers folder.
- Click this folder. The details pane lists the domain controllers that are located in this site.
- Right-click the server to be moved and select Move.
- In the Move Server dialog box, shown in Figure 3.41, select the site for the server and then click OK.
Figure 3.41 Moving a domain controller to a new site.
- The moved server appears under its site in Active Directory Sites and Services.
)
Specifying a Licensing Server
A licensing computer collects information from within the site for use by the Windows Server 2003 licensing administration tool. It need not be a domain controller, but it should be located within its site. Follow Step by Step 3.17 to select a licensing computer for a site.
Step by Step 3.17 Selecting a Licensing Server
- In the console tree of Active Directory Sites and Services, click the site to which you want to assign a licensing server. This action displays, among others, a Licensing Site Settings container in the details pane.
- Right-click this container and choose Properties.
- On the Licensing Site Settings Properties dialog box, click Change.
- In the Select Computer dialog box that appears, type or browse to the name of the desired server, as shown in Figure 3.42. Then click OK.
Figure 3.42 Selecting a licensing site server.
- Click OK to close the Licensing Site Settings Properties dialog box.
)
Configuring Site Boundaries
- Objective
-
Manage an Active Directory site
- Configure site boundaries
As we have emphasized, the purpose of using sites is to control replication of Active Directory information over slow links between geographically distinct locations. By itself, Active Directory has no knowledge of an organization's physical network topology. Administrators must model the enterprise's site topology to mirror the physical network. You can accomplish this by configuring each site to represent one or more IP subnets that are connected by high-speed links, as described in Step by Step 3.18.
Step by Step 3.18 Assigning a Subnet to a Site
- Click Start, Administrative Tools, Active Directory Sites and Services.
- In the console tree, right-click the Subnets folder and choose New Subnet.
- In the New Object—Subnet dialog box, type the subnet IP address and subnet mask, as shown in Figure 3.43.
Figure 3.43 You can assign a subnet to a site from the New Object—Subnet dialog box.
- The information is shown on the New Object—Subnet dialog box in the form of a network address/bits masked. Click OK.
- In the Site Name field, select the site to which the subnet should belong and then click OK.
- You return to the Active Directory Sites and Services snap-in. The subnet you created appears under the Subnets folder.
)
You can configure a limited set of properties for each subnet you have assigned. Follow Step by Step 3.19 to configure subnet properties.
Step by Step 3.19 Configuring Subnet Properties
- In the console tree, right-click the subnet and choose Properties.
- On the General tab of the Properties dialog box, type a description for the subnet, as shown in Figure 3.44. This description is for information purposes only.
Figure 3.44 The Subnet Properties dialog box enables you to specify a description and location for the subnet and change the site with which it is associated.
- If you need to change the site to which the subnet is assigned, you can do so from the Site drop-down list box.
- On the Location tab, you can type the location for the subnet. This location is also for information purposes only.
- The Object and Security tabs function in a similar manner to those on other Properties dialog boxes.
)
Configuring Site Links
- Objective
-
Implement an Active Directory site topology
- Configure site links
A site link is a path that Active Directory uses to replicate information between sites. Replication cannot take place between sites unless site links have been created. Because of the limited bandwidth that usually exists between sites, Active Directory handles intersite replication differently than intrasite. In a nutshell, intersite replication is compressed, whereas intrasite replication is not compressed. Intersite replication takes place at a lower, configurable frequency. We discuss intersite replication and its configuration later in this chapter.
Site links can use either of two intersite transport protocols for replicating data: Remote Procedure Call (RPC) over IP and Simple Mail Transfer Protocol (SMTP).
- RPC over IP—This protocol is the default replication method and the only one that supports replication within a domain. It enables low-speed, synchronous replication of all directory partitions using remote procedure calls.
- SMTP—This protocol is asynchronous email–based replication that can be used to replicate the schema and configuration partitions of Active Directory and the global catalog between domains. You should use this protocol if the reliability of the link is not good. You need to install an enterprise certification authority (CA) if you are using this transport protocol. It signs the SMTP messages that are sent over this protocol. SMTP also must be installed on domain controllers using this site link.
Site links are not created automatically. As outlined in Step by Step 3.20, you can create site links by using Active Directory Sites and Services.
Step by Step 3.20 Creating Site Links
- In the console tree of Active Directory Sites and Services, expand the Inter-Site Transports folder to reveal the IP and SMTP subfolders.
- Right-click the folder corresponding to the transport protocol that is to be used and choose New Site Link.
- In the New Object—Site Link dialog box, type a name for the site link (see Figure 3.45). Then make sure that the sites to be linked appear in the Sites in This Site Link field and click OK.
Figure 3.45 Creating a site link.
)
Site Link Bridges
By default, Active Directory bridges all site links. In other words, Active Directory creates a chain of site links that allow any two domain controllers to communicate directly with each other, whether or not they are directly linked with a site link. Implicitly, all site links for a single transport (IP or SMTP) are contained in one site link bridge for that transport.
By default, all site links are bridged automatically. These links are also known as transitive site links. In some cases, you might have to disable automatic site link bridging and create your own site link bridges, such as in the following situations:
- Your network is not completely routed. In other words, not all domain controllers can communicate with one another.
- A security policy prevents all domain controllers from communicating directly with one another.
- In some situations, the enterprise contains a large number of sites that are not well connected.
Follow the procedure in Step by Step 3.21 to disable automatic site link bridging and create your own site link bridges.
Step by Step 3.21 Configuring Site Link Bridges
- In the console tree of Active Directory Sites and Services, expand the Inter-Site Transports folder to reveal the IP and SMTP subfolders.
- Right-click the transport (IP or SMTP) whose site link bridges you want to configure and choose Properties.
- In the Properties dialog box for the transport (see Figure 3.46), clear the check box labeled Bridge All Site Links and then click OK.
Figure 3.46 Disabling automatic site link bridging.
- Right-click the transport again and choose New Site Link Bridge.
- In the New Object—Site Link Bridge dialog box (see Figure 3.47), type a name for the site link bridge, ensure that the site links you want bridged appear in the Site Links in This Site Link Bridge field, and then click OK.
Figure 3.47 Creating a site link bridge.
)
)
Knowledge Consistency Checker
The Knowledge Consistency Checker (KCC) is a process that runs automatically on all domain controllers and creates Active Directory replication topologies, both intrasite and intersite. It creates optimum topologies at 15-minute intervals according to the conditions that exist at that time. As new sites and domain controllers are added, the KCC adjusts the replication topology to accommodate these changes. It uses a bidirectional ring topology that provides at least two paths between each domain controller for fault tolerance, and no more than three hops between any two domain controllers to reduce replication latency. It automatically adjusts the intrasite replication topology without administrator intervention.
For intersite replication, the KCC works from a single domain controller called the Inter-Site Topology Generator (ISTG) in each site and uses the information you have configured in Active Directory Sites and Services. It designates one or more servers, known as bridgehead servers, for each site to ensure that changes to Active Directory are replicated only once across any given site link. Although the KCC usually designates its own bridgehead servers, you can manually designate bridgehead servers from Active Directory Sites and Services.
The KCC normally runs in the background without the need for any type of configuration. If you need to force the KCC to run at a given time, you can run the repadmin command-line utility or the replmon GUI-based utility. These tools are both located in the Support\Tools folder of the Windows Server 2003 CD-ROM. We discuss the use of this tool in Chapter 4, "Maintaining an Active Directory Infrastructure."
Configuring Connection Objects
A connection object is an Active Directory object that represents an inbound connection to a domain controller. It is utilized for replication from other domain controllers to the domain controller on which it is configured. The KCC in a site automatically creates connection objects between domain controllers within its site as well as connection objects for replication to other sites.
Although the KCC endeavors to create an optimum set of connection objects, the administrator might have to configure connection objects manually if the connections created by the KCC do not link the specific domain controllers she wants to be connected.
Follow Step by Step 3.22 to create a manual connection object.
Step by Step 3.22 Creating and Configuring a Connection Object
- In the console tree of Active Directory Sites and Services, expand the Servers folder in the site containing the domain controller for which you want to create an inbound connection object.
- Right-click the NTDS Settings folder under the desired server and select New Active Directory Connection.
- In the Find Domain Controllers dialog box shown in Figure 3.48, select the server with which you want to create a connection and then click OK.
Figure 3.48 The Find Domain Controllers dialog box enables you to select the outbound server.
- By default, the new connection object is named for the server with which you are creating the connection. In the New Object–Connection dialog box, accept this name or type a different name and then click OK. The new connection object is added to the details pane.
- To modify the properties of the connection object, right-click it and choose Properties to display the dialog box shown in Figure 3.49. From here, you can configure any of the following options:
- Description—Type an optional description for the connection object.
- Transport—Select RPC, IP, or SMTP. You would not normally change this from the default of RPC.
- Change Schedule—Select the times in which you want the replication schedule from its default of four times per hour to once or twice per hour, or none.
- Replicate From Click Change to change the server from which replication takes place. This displays the same Find Domain Controllers dialog box shown in Figure 3.48.
- Object tab Display information about the connection object, including its LDAP canonical name, the creation and modification dates, and update sequence numbers (USNs). This tab does not contain configurable items.
- Security tab Configure permissions for users or groups. See Chapter 5, "Planning User, Computer, and Group Strategies."
Figure 3.49 The Properties dialog box enables you to configure the connection object.
- Click OK when finished.
)
)
Inter-Site Topology Generator
As we have already noted, the ISTG is the domain controller used by the KCC to create the intersite replication topology. The ISTG considers the cost of intersite connections and checks whether any domain controllers have been added to or removed from the site; the ISTG provides this information to the KCC, which then adds or removes connection objects to optimize replication as required. Only one domain controller per site acts as the ISTG. If the forest is operating at the Windows Server 2003 forest functional level, the KCC uses an improved, randomized process to determine the site's bridgehead servers. It distributes the bridgehead replication workload more evenly among a site's domain controllers, resulting in improved replication efficiency. The algorithm used allows a domain to contain as many as 3,000 sites.
You can use the dcdiag tool from the Support\Tools folder of the Windows Server 2003 CD-ROM to identify the ISTG computer in each site.
Preferred Bridgehead Servers
- Objective
-
Implement an Active Directory site topology
- Configure preferred bridgehead servers
The bridgehead server is the domain controller designated by each site's KCC to take charge of intersite replication. This server receives information replicated from other sites and then replicates it to the site's other domain controllers. It ensures that the greatest portion of replication takes place within sites rather than between them.
Usually, the KCC automatically decides which domain controller will act as the bridgehead server. If necessary, you can designate a specific domain controller to be the bridgehead server to specify the best conditions for intersite replication. Follow Step by Step 3.23 to designate a preferred bridgehead server.
Step by Step 3.23 Designating a Preferred Bridgehead Server
- In the console tree of Active Directory Sites and Services, expand the site where you need to designate a bridgehead server and then expand the Servers folder to locate the available servers.
- Right-click the desired domain controller and choose Properties.
- On the General tab of the server's Properties dialog box, select the transport protocol(s) for which this domain controller should be a bridgehead server and then click Add, as shown in Figure 3.50.
Figure 3.50 Designating a bridgehead server for the IP transport protocol.
- Click OK.
)
Configuring Replication Schedules
- Objective
-
Manage an Active Directory site
- Configure replication schedules
We have already mentioned that all domain controllers act as peers and that most changes to Active Directory can be made at any domain controller. Active Directory uses the process of multimaster replication to propagate these changes to other domain controllers in the domain. In addition, the global catalog is replicated to all other global catalog servers in the forest. Application directory partitions are replicated to a subset of domain controllers in the forest, and the schema and configuration partitions of Active Directory are also replicated to all domain controllers in the forest. You can see that replication is an important process that must take place in a timely manner so that updates to Active Directory are synchronized properly among all domain controllers in the forest. The amount of replication that is necessary to maintain Active Directory could easily overwhelm network bandwidth, especially on slow-speed WAN links.
In this section, you learn how to manage replication in Active Directory by configuring replication schedules within and between sites. But before we look at managing replication, we provide an overview of how it operates.
What Does Active Directory Replicate?
The following is an overview of the types of information that Active Directory must replicate on a timely basis. These types are based on the Active Directory partitions you learned about in Chapter 1.
- Schema data—We discussed schema modification earlier in this chapter. Recall that this information contains definitions for all objects and their attributes in the Active Directory forest and is common to all domain controllers in the forest. It must be kept up-to-date so that Active Directory can function properly.
- Configuration data—This data includes information related to the design of the Active Directory forest, including sites, trees, and domains, and their organization within the hierarchy. All domain controllers in the forest require this information to function properly.
- Application data—This data includes application-specific data and DNS information for Active Directory–integrated DNS zones that need to be replicated throughout the forest. Some of this information might have to be replicated to only a subset of the domain controllers in the forest.
- Domain data—This data includes information about all objects in an individual domain, such as users, groups, computers, printers, shared folders, and so on. Active Directory replicates all this information to every domain controller in the domain. In addition, a read-only subset of this information is contained in the global catalog and replicated to all global catalog servers in the forest.
How Does Active Directory Replication Work?
Active Directory replicates data between domain controllers using the following two standard networking protocols:
- Remote Procedure Call (RPC) over Internet Protocol (IP)—Used for both intrasite and intersite replication, RPC over IP uses remote procedure calls for replication. It employs both Kerberos-based authentication and data encryption to keep data secure.
- Simple Mail Transfer Protocol (SMTP)—This email protocol is used only for intersite replication when a direct or reliable IP-based path is unavailable. It is used for replication only between two domain controllers that are located in different domains as well as different sites. It requires an enterprise certification authority (CA) to operate. The CA signs SMTP messages as they are exchanged between domain controllers, ensuring their authenticity. SMTP does not replicate the domain partition of Active Directory; it replicates only the schema, configuration, and application partitions. In addition, SMTP replication ignores schedules.
Active Directory uses a numerical sequencing method called the update sequence number (USN) to keep track of replicated updates. This method is more reliable than using time stamps because the latter method depends on exact synchronization of the clocks on all domain controllers, which is hard to maintain. However, Active Directory also uses a time stamp to resolve conflicting changes.
A USN is a 64-bit number that is maintained at each domain controller in the forest. Whenever an update is initiated, the originating domain controller issues what is known as an originating update, which determines the kind of update being made to the Active Directory database. At the same time, the domain controller increments the USN by one and associates the updated USN with the originating update. Other domain controllers use the USN to determine what updates they need to receive. We discuss the use of the USN to track replication and troubleshoot problems in Chapter 4.
Active Directory replication works by a pull process. In other words, individual domain controllers request updates from their replication partners at a known interval, which is five minutes by default. It checks the USNs for each replication partner and uses them to request any required updates. If a domain controller is offline for any reason, it can use the USN to get up to date properly. This process is in contrast to a push process in which domain controllers send updates immediately to their replication partners rather than wait for requests. An offline domain controller would miss pushed updates and not be up to date. In addition, a domain controller might receive the same update from more than one source, which translates to a waste of bandwidth.
In the event that two different administrators happen to modify the same attribute of the same object at the same time on different domain controllers, a conflict could occur. In this case, Active Directory uses the timestamp to resolve the conflict, and the latest update wins. If the changes take place at the exact same millisecond, the change with the higher globally unique ID wins.
Intrasite Replication
We previously discussed how the KCC automatically creates and adjusts the intrasite replication topology. The KCC ensures that each domain controller replicates with at least two others, so that if one is temporarily unavailable, no domain controller will miss an update. KCC uses a default bidirectional ring topology, with additional connections as needed to keep the number of hops between replication partners to three or fewer.
Replication to the first replication partner takes place automatically on the basis of change notification after the administrator has configured an update. After waiting for 15 seconds, the source domain controller sends an update notification to its closest replication partner and sends additional notifications to other partners at 3-second intervals. After receiving the notification, the replication partners send update requests to the source domain controller, which then replicates the change to the partners. However, some updates such as password changes and account lockouts are replicated immediately. Because it is assumed that high LAN bandwidth is available for intrasite replication, data is not compressed during the replication process.
Intrasite replication is completely automatic and requires no additional configuration after you have created and validated your sites, although you can modify intrasite replication if necessary, as we described previously in the section "Configuring Connection Objects." However, intersite replication can be configured and managed; we now turn our attention to managing intersite replication schedules.
Intersite Replication
One important use of sites is to control replication traffic between network segments located across WAN links. The high frequency of intrasite replication requires a high-speed LAN link (10Mbps or faster) to work properly. Table 3.1 compares several characteristics of intersite versus intrasite replication.
Table 3.1. Comparison of Intersite and Intrasite Replication
|
Characteristic |
Intersite |
Intrasite |
|
Compression |
Compressed |
Uncompressed |
|
Interval |
Scheduled, configured |
Frequent, automatic |
|
Transport Protocol |
SMTP, RPC over IP |
RPC over IP |
|
Connection Type |
According to site link cost |
Between all DCs in ring topology |
Active Directory allows you to schedule intersite replication so that you can control how much bandwidth it consumes. This capability is important because bandwidth affects the efficiency of replication. Replication frequency is a trade-off between keeping Active Directory on remote domain controllers up to date and using a high amount of bandwidth on a slow link. By default, replication takes place every 180 minutes (3 hours), and can take place 24 hours a day, 7 days a week. You can configure the replication process to take place at times of low bandwidth usage, such as late at night. Step by Step 3.24 shows you how to configure intersite replication.
Step by Step 3.24 Configuring Intersite Replication Intervals
- Click Start, Administrative Tools, Active Directory Sites and Services.
- If necessary, expand the Sites folder in the console tree to locate the Inter-Site Transports folder.
- Expand this folder and click either IP or SMTP, whichever contains the site link whose replication schedule you want to modify (see Figure 3.51).
Figure 3.51 You can configure site link properties from the IP or SMTP folder of Inter-Site Transports in Active Directory Sites and Services.
- In the details pane, right-click the site link and choose Properties to display the General tab of the Properties dialog box for the site link (see Figure 3.52).
Figure 3.52 You can modify the intersite replication schedule in the Properties dialog box for the site link of concern.
- In the text box labeled Replicate Every, type the number of minutes between replications and then click OK.
)
)
Active Directory processes the interval you enter as the nearest multiple of 15 minutes, up to a maximum of 10,080 minutes (one week).
Notice that the Properties dialog box for the site link contains two additional tabs: Object and Security. These tabs also exist for the Properties dialog box of most objects in the Active Directory Sites and Services snap-in. Their functions are the same as described previously for Active Directory connection objects.
If you need to specify that replication not take place during certain times of the day (such as business hours when other WAN traffic must be able to proceed without delay), you can restrict the times that replication takes place. To do so, follow Step by Step 3.25.
Step by Step 3.25 Restricting Intersite Replication Times
- Follow steps 1–4 of Step by Step 3.24 to access the Properties dialog box for the site link whose replication times you want to modify.
- Click Change Schedule, and in the Schedule for link name dialog box, select the time block for which you want to deny replication, as shown in Figure 3.53.
Figure 3.53 You can configure a time when replication is not available in the Schedule for link name dialog box.
- Select Replication Not Available and then click OK twice to return to Active Directory Sites and Services.
)
You might have to ignore the replication schedule so that replication can take place at any time of day or night. This is useful if you need to force replication of a large number of changes. To ignore replication schedules, follow Step by Step 3.26.
Step by Step 3.26 Ignoring Replication Schedules
- Follow steps 1–3 of Step by Step 3.24 to access the IP or SMTP folders in the Inter-Site Transports folder.
- In the console tree, right-click the replication method you want to modify and choose Properties.
- In the Properties dialog box for the replication method, select the Ignore Schedules check box, as shown in Figure 3.54, and then click OK.
Figure 3.54 You can choose to ignore replication schedules from the IP or SMTP Properties dialog box.
)
Performing this procedure causes Active Directory to ignore availability schedules and replicate changes to Active Directory at the configured interval. Site links are always available for replication. Clear the Ignore Schedules check box to re-enable the replication schedules.
Notice that this is the same dialog box from which you can choose whether to bridge all site links, as we discussed in the "Active Directory Site Topology" section of this chapter.
Manually Forcing Replication
Sometimes you might need to have Active Directory replication occur immediately, such as after the addition of new users or groups for a branch office. You can easily force replication from Active Directory Sites and Services. Step by Step 3.27 shows you how.
Step by Step 3.27 Manually Forcing Replication
- In the console tree of Active Directory Sites and Services, expand the server to which you want to force replication, to locate the NTDS Settings folder.
- Select this folder to display the connection objects in the details pane.
- Right-click the desired connection object and choose Replicate Now (see Figure 3.55).
Figure 3.55 You can force replication from the NTDS Settings folder in Active Directory Sites and Services.
)
Configuring Site Link Costs
- Objective
-
Manage an Active Directory site
- Configure site link costs
In some cases, you might have more than one physical link between two sites. For example, you might have a dedicated T1 line connecting your head office to the branch office. Because of occasional downtime on the T1 link, you might also have set up a dial-up link over regular phone lines to the branch office. Obviously, you want replication to use the T1 link at all times when it is available. Active Directory allows you to provide additional information about the cost of the various site links.
The KCC uses this information to determine the optimum link to be used during replication. KCC will use the other link (in this case, the dial-up link) when the optimum one is unavailable. Although the site link cost factor can include the monetary cost, it is much more than just a monetary cost; it includes variables such as bandwidth, reliability, and availability of a given line. When available, the KCC always chooses the lowest cost link for replication.
By default, when you first create a site link, it is assigned a cost of 100. In the example used here, you might want to set the cost of the T1 link at 50 and keep the cost of the dial-up link at 100.
You can extend this example to cover more complex networks. Consider the five-site network shown in Figure 3.56. This network provides two replication paths between domain controllers located in sites A and E. As shown in Figure 3.56, you should configure site link costs according to bandwidth, availability, and reliability.
)
Figure 3.56 An example of site links and costs in a multisite network.
For replication between sites A and E, the total site link cost is the sum of the costs of all links crossed by packets transmitted between the sites. Going by way of sites B and C, the cost is (50 + 100 + 200) = 350, whereas going by way of site D, the cost is (150 + 150) = 300. Consequently, the preferred replication path is through site D. If it is not acceptable for the replication path to utilize two dial-up links, you should adjust the costs so that the path using two dedicated plus one dial-up links becomes the preferred one.
As Step by Step 3.28 shows, modifying the site link cost is a simple procedure.
Step by Step 3.28 Configuring the Site Link Cost
- Follow steps 1–3 of Step by Step 3.24 to access the IP or SMTP folder in the Inter-Site Transports folder.
- Open the folder containing the site link whose cost you want to modify. The details pane displays information about the site link (refer to Figure 3.51).
- Right-click the link and choose Properties. This opens the Properties dialog box for the site link (refer to Figure 3.52).
- Type a new value in the Cost box or use the up/down arrows to select the desired value. Then click OK.