- Introduction
- Active Directory Trust Relationships
- Active Directory Forest and Domain Structure
- Active Directory Site Topology
- Chapter Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Active Directory Site Topology
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 may 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 may 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 provides for fault tolerance in replication.
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.38, and then click OK.
-
You receive a message box listing other tasks you should perform, as shown in Figure 3.39. Click OK.
-
The site you created appears in the console tree of Active Directory Sites and Services, and several default containers appear in the details pane.
){kind=small}
Figure
3.38 You use the New Object—Site dialog box to create a new site.
)
Figure
3.39 Windows reminds you of several tasks to be completed after creating
a site.
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.40, select the site for the server and then click OK.
-
The moved server appears under its site in Active Directory Sites and Services.
)
Figure
3.40 Moving a domain controller to a new site.
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.41. Then click OK.
-
Click OK to close the Licensing Site Settings Properties dialog box.
)
Figure
3.41 Selecting a licensing site server.
Configuring Site Boundaries
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.42.
-
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.
)
Figure
3.42 You can assign a subnet to a site from the New Object—Subnet
dialog box.
NOTE
Site Naming Conventions Subnet locations specified on the Location tab should follow a specific naming convention for your organization. These locations link to printer tracking in Active Directory. Refer to "Establishing a Naming Convention for Printer Locations" in Windows Server 2003 Help and Support Center for more information.
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.43. This description is for information purposes only.
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.
)
Figure
3.43 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.
Configuring Site Links
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 needs to 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.44). Then make sure the sites to be linked appear in the Sites in This Site Link field and click OK.
)
Figure
3.44 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.
TIP
Site Links You should be aware of the differences between IP and SMTP and know when you should use SMTP rather than IP for configuring a site link.
By default, all site links are bridged automatically. These links are also known as transitive site links. In some cases, you may need 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.45), clear the check box labeled Bridge All Site Links and then click OK.
-
Right-click the transport again and choose New Site Link Bridge.
-
In the New Object—Site Link Bridge dialog box (see Figure 3.46), 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.45 Disabling automatic site link bridging.
)
Figure
3.46 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.
NOTE
Different Topologies for Different Purposes The KCC generates separate topologies for each of the schema, configuration, application, and domain partitions, and the global catalog, according to their individual requirements.
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."
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
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.22 to designate a preferred bridgehead server.
WARNING
Be Cautious About Choosing Bridgehead Servers Manually If you allow the KCC to select a bridgehead server and this server fails, the KCC will select another one. However, if you select a bridgehead server yourself and it fails, the KCC will not choose another bridgehead server.
STEP BY STEP
3.22 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.47.
Click OK.
)
Figure
3.47 Designating a bridgehead server for the IP transport protocol.
Configuring Replication Schedules
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 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 may need 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. This 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.
The 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 may 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 time stamp 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.
NOTE
Multiple Replication Topologies Active Directory uses one topology for the schema and configuration partitions and another one for the domain partition. In some cases, a third replication topology may exist for the application partition because data stored in this partition may not need to be replicated to all domain controllers. An administrator can explicitly route application partition data to selected domain controllers within a forest or to all domain controllers in a domain.
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. 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 |
NOTE
Intersite Replication Is Compressed To further conserve bandwidth, Active Directory compresses all updates to Active Directory above 50KB in size when they are replicated. Because the compression ratio can be as high as 10:1, this can save a lot of bandwidth. Should you have bandwidth to spare but are limited in processing power, you can configure Active Directory to shut off compression. In addition, you may be able to increase replication latency to use less bandwidth in the long run. This is true because compression takes place only above 50KB.
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.23 shows you how to configure intersite replication.
STEP BY STEP
3.23 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, which-ever contains the site link whose replication schedule you want to modify (see Figure 3.48).
-
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.49).
-
In the text box labeled Replicate Every, type the number of minutes between replications and then click OK.
){kind=small}
Figure
3.48 You can configure site link properties from the IP or SMTP folder
of Inter-Site Transports in Active Directory Sites and Services.
)
Figure
3.49 You can modify the intersite replication schedule in the Properties
dialog box for the site link of concern.
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. These tabs have the following functions:
Object tab Displays information about the site link, including its LDAP canonical name, the creation and modification dates, and USNs. This tab does not contain configurable items.
Security tab Enables you to configure permissions for users or groups. See Chapter 5, "Planning User, Computer, and Group Strategies."
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.24.
STEP BY STEP
3.24 Restricting Intersite Replication Times
-
Follow steps 1–4 of Step by Step 3.23 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.50.
-
Select Replication Not Available and then click OK twice to return to Active Directory Sites and Services.
)
Figure
3.50 You can configure a time when replication is not available in the
Schedule for link name dialog box.
NOTE
Shortcut Link If you have recently accessed Active Directory Sites and Services (as in performing Step by Step 3.23), a shortcut link will appear on the left side of the Windows Server 2003 Start menu.
You may need 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.25.
STEP BY STEP
3.25 Ignoring Replication Schedules
Follow steps 1–3 of Step by Step 3.23 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.51, and then click OK.
)
Figure
3.51 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.
TIP
Remember the Different Options Available for Scheduling Replication If you need replication to occur more or less frequently than the default 3-hour interval, specify the desired interval. This interval should not be less than the 15-minute maximum intrasite replication interval. If you do not want replication to occur at certain times of the day, specify the appropriate replication schedule. If you need replication to take place when it is not scheduled, select the Ignore Schedules option.
Guided Practice Exercise 3.2
Creating and Configuring Sites
The Widgets company you have been working with has a head office and a factory location connected by a T-1 with 1.544Mbps bandwidth line. The server that was the Windows NT PDC (Server01) is located at the head office, whereas the former BDC (Server02) is located at the factory. There is also a warehouse that does not currently have a domain controller, and is connected to the head office with an ISDN line. There is no direct connection between the factory and the warehouse.
This exercise requires you to create and configure sites for the three locations. You also need to create the appropriate site links and bridges. The head office site is on the 172.22.0.0 subnet with a subnet mask of 255.255.248.0, the factory site is on the 172.22.8.0 network with the same subnet mask, and the warehouse site is on the 172.22.16.0 network with the same subnet mask.
After you have created the site links and bridges, you need to configure replication between the sites. The company wants replication to take place between the head office and the factory every four hours, day and night. Between the head office and the warehouse, the company wants replication to take place every six hours outside the 8 a.m. to 5 p.m. business day only.
Try to work through the steps on your own, working from the two domain controllers. If you need to see a possible solution, follow these steps, and refer to the Step by Step exercises for more details:
Open Active Directory Sites and Services at the Server01 computer.
Select the Default-First-Site-Name and rename this site Office.
Create a new site named Factory and a third site named Warehouse. Use the default site link.
Expand the Office site to locate the two servers and move Server02 to the Factory site.
To add a subnet, right-click the Subnets container and choose New Subnet. Type 172.22.0.0 as the subnet and 255.255.248.0 as the mask, select the Office site, and then click OK.
Repeat step 5 to add subnets for the factory and the warehouse.
Expand the Inter-Site Transports folder and click IP.
Rename the default site link Office to Factory.
Right-click this link and choose Properties. On the Properties dialog box, remove the Warehouse site from this link.
Create a new site link named Office to Warehouse. For this link, include the Office and Warehouse sites.
Right-click the IP transport and select Properties; then clear the Bridge All Site Links check box.
Right-click the IP transport and select New Site Link Bridge. Name this bridge Factory to Warehouse, ensure that the two site links you have configured are in this site link bridge, and then click OK.
Right-click the Office to Factory site link and choose Properties. In the Replicate Every spin box, type 240 and then click OK.
Right-click the Office to Warehouse site link and choose Properties. In the Replicate Every spin box, type 360. Click Change Schedule, and in the Schedule for Office to Warehouse dialog box, specify that replication is not available between 8 a.m. and 5 p.m. (white areas).
Manually Forcing Replication
Sometimes you may 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.26 shows you how.
STEP BY STEP
3.26 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.52).
)
Figure
3.52 You can force replication from the NTDS Settings folder in Active Directory
Sites and Services.
NOTE
Forced Replication Is One Way Only When you manually force replication using this procedure, this forces replication to occur to the selected object only. To ensure that the replication occurs immediately, you should perform this procedure on both sides of the link. Use the Connect To option to connect to the other domain controller and initiate a manually forced replication in the other direction.
Keeping Replication at Bay
A few months ago, a major newspaper with branch offices across the country was covering a breaking news story. A couple of photographers using digital cameras were trying to upload photos to the newspaper's main office several hundred miles away. However, transmitting a single photo over the paper's dedicated ISDN connection was taking almost an hour. Consequently, only a few photos were transmitted before the deadline, and the paper went to press without the desired coverage. The resulting news story was inferior to that provided by a competing paper.
Management contacted the network administration staff to determine what went wrong and ensure this situation did not happen again. At first, the administrators were puzzled that it had taken place. They had prided themselves on setting up Active Directory to keep information at the branch office domain controllers current, but had not taken into consideration the amount of traffic that could be generated. In addition, a lot of other network traffic is transmitted over the ISDN line in the course of everyday business. Analyzing traffic when branch office staff uploaded a few more photos, the administrators discovered the line was 100% utilized for a period of time every 30 minutes. The administrators then remembered that they had configured a 30-minute intersite replication interval in Active Directory. Changing this interval to 3 hours resulted in reduced utilization of the line and much improved capability to transmit photos and other important data.
Configuring Site Link Costs
Manage an Active Directory site.
-
Configure site link costs.
In some cases, you may 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 may 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.53. This network provides two replication paths between domain controllers located in sites A and E. As shown in Figure 3.53, you should configure site link costs according to bandwidth, availability, and reliability.
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 link becomes the preferred one.
)
Figure
3.53 An example of site links and costs in a multisite network.
NOTE
Site Link Bridge Costs You can extend the principle of site link costs to site link bridges. The cost of a site link bridge is merely the sum of the costs of all site links contained within the bridge.
As Step by Step 3.27 shows, modifying the site link cost is a simple procedure.
STEP BY STEP
3.27 Configuring the Site Link Cost
Follow steps 1–3 of Step by Step 3.23 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.48).
-
Right-click the link and choose Properties. This opens the Properties dialog box for the site link (refer to Figure 3.49).
Type a new value in the Cost box or use the up/down arrows to select the desired value. Then click OK.
Case Study: A Contract with a Major Manufacturer
Essence of the Case
This case involves establishing a trust relationship that will provide the appropriate level of access, and no more, between the forests of the two companies. You need to note carefully several issues as you study this case:
-
Employees of On The Go Ltd. need to access only certain resources of Bluebonnet and not the entire enterprise. In addition, not all geographical regions of On The Go Ltd. need access.
-
Employees of Bluebonnet have no need to access any resources of On The Go Ltd.
-
Because both companies are involved in creation of the trusts, communication between IT staff, as well as management, at both companies is essential to the success of the project.
Scenario
In the preceding chapter, you looked at how the administrators at On The Go Ltd. built their Active Directory infrastructure from the head office root domain to the four child domains. Then they created a site for each distribution center and moved the appropriate domain controllers and member servers to each site.Last month, executives at On The Go Ltd. signed a multimillion dollar contract with Dallas, Texas–based Bluebonnet Snacks and Notions Ltd. to distribute its products throughout its chain of client truck stops. Currently, the com-pany's contract covers only distribution centers located in the United States; however, it may expand the contract to include first Canada, and later Mexico, in the near future. Bluebonnet Snacks and Notions operates a three-domain Active Directory forest with the domain names bluebonnet.local, operations.bluebonnet.local, and distribution.bluebonnet.local. The domains have the following functions:
-
bluebonnet.local—The forest root domain contains all resources related to company management, IT, human resources, and so on.
-
operations.bluebonnet.local—This domain is related to acquisitions of ingredients and manufacturing of the company's products.
-
distribution.bluebonnet.local—This domain contains all resources related to the distribution of the company's products through contracts it has signed with several distributors, including On The Go Ltd.
Analysis
We have a scenario in which employees at On The Go Ltd. need frequent access to another Active Directory forest, namely Bluebonnet Ltd. Obviously, some sort of trust relationship needs to be set up between the two forests. Think about the various trust relationships we studied in this chapter. What kind of trust relationship would you implement?
Would you implement a forest trust? As you learned, this type of trust enables complete trust relationships between all domains in the relevant forests. It is simple to set up and configure from each end. But employees of On The Go Ltd. do not need to access Bluebonnet's administrative resources; indeed, Bluebonnet wants to protect these resources from external access.
What about a shortcut trust? The answer is simple. This type of trust is between child domains of the same forest, and not between different forests.
We are left with the obvious choice: external trusts. As you recall, these individual trust relationships are set up between two domains in different forests. Employees of On The Go Ltd. need to access only one domain in the Bluebonnet forest: distribution.bluebonnet.local. In addition, the current contract is for U.S. distribution centers only. Consequently, we need to set up the trust only from the east.onthego.local and west.onthego.local domains. Is this totally correct? Recall from the geographic information outlined in Chapter 2 that the Fairbanks, Alaska, distribution center is connected only to the Calgary distribution center, and for this reason, this distribution center was included in the Canada.onthego.local domain. Consequently, you need to set up another external trust relationship with that domain.
What about the direction of these trusts? Think of what has to be done. Do employees of Bluebonnet need access to On The Go's resources? No. So you do not want a two-way trust relationship. Think carefully about the choice between a one-way incoming and a one-way outgoing trust, from On The Go's perspective. An outgoing trust enables users in the Bluebonnet domain to access resources in On The Go. This is not correct. You want to configure a one-way incoming trust, which enables users in the On The Go domains (the sales associates and their managers) to access resources (product information, inventories, and so on) at Bluebonnet. This trust enables On The Go's users to be authenticated to Bluebonnet.
You also need to consider the type of authentication: Recall that you can choose between domainwide and selective authentication. This choice should be simple: On conferring with Bluebonnet's management and IT staff, you learn that On The Go employees should not have access to some resources in the distribution.bluebonnet.local domain. So you choose selective authentication.
Having made these decisions, you can go ahead and use the New Trust Wizard to create the trust from On The Go's side. An administrator in the Bluebonnet domain needs to either grant you the appropriate permission to create both sides of the trust or he needs to create Bluebonnet's side to have the trust fully implemented. After the trusts are created and validated from both ends, this stage of the project is complete.
Later, we will look at assigning the appropriate permissions so that sales associates and their managers can access only the appropriate resources in the distribution.bluebonnet.local domain.
In this chapter, you continued to build on the basics of Active Directory that you learned about in Chapter 2. You began by exploring the various types of trust relationships available in Active Directory. Should your organization employ a multiple forest design, you need to manually create trust relationships so that users in one forest can access resources in other forests.
Two types of crossforest trust relationships are available: external trusts, which are trusts that are set up between two specific domains, and forest trusts, which are trusts that involve complete two-way trust relationships between all domains in the forests involved.
In addition, you can set up shortcut trusts, which are specific trusts between two subdomains in the same forest. This type of trust relationship speeds up authentication and data access by allowing the trust path to proceed directly between the domains rather than through the parent domains.
Having set up these trust relationships, you can now manage them in several ways. We showed you how to validate trust relationships to ensure that the trusts have been properly created, change the authentication scope of a trust, and configure name suffix routing in forest trusts. Finally, you learned how to remove a crossforest trust.
Next, you learned about the classes of objects and their attributes that make up the Active Directory schema. Because the schema is vital to the function of Active Directory, Microsoft has implemented safeguards to help ensure only authorized schema modifications are performed. These safeguards include registering and installing the Schema snap-in before it can be used and being a member of the Schema Admins group. Microsoft recommends that you add users to this group only when schema modifications are required and remove them after they are completed.
You also learned what a UPN suffix is and how to add or remove one. The UPN suffix is an additional suffix that can be used to facilitate user logons throughout a forest and to conceal the true domain structure of the enterprise. It is especially useful for users who have long child domain names.
You also learned about creating and configuring sites in Active Directory. You learned about adding domain controllers to sites, configuring site links and site link bridges, and designating preferred bridgehead servers. You also learned what the ISTG and KCC do. We will cover additional aspects of configuring sites, including replication, site link costs, and site link boundaries, in the next chapter.
Finally, you learned about Active Directory replication. Whereas intrasite replication is essentially automatic, being determined by the KCC, you can configure intersite replication according to the bandwidth and availability of WAN links connecting the sites. You can modify replication intervals and restrict replication to certain times of the day when other WAN traffic is low. You can also specify cost values for site links that determine which link is given priority during replication.