Managing Sites
On This Page
Overview The KCC and Replication Topology Bridgehead Server Selection Site Management Tasks and Procedures Adding a New Site Procedures for Adding a New Site Adding a Subnet to the Network Procedures for Adding a Subnet Linking Sites for Replication Procedures for Creating a Site Link Changing Site Link Properties Procedures for Configuring Site Links Moving a Domain Controller to a Different Site TCP/IP Settings Preferred Bridgehead Server Status Procedures for Moving a Domain Controller to a Different Site Removing a Site Procedures for Removing a Site
Overview
An Active Directory site object represents a collection of Internet Protocol (IP) subnets, usually constituting a physical Local Area Network (LAN). Multiple sites are connected for replication by site link objects.
Sites are used in Active Directory to:
Enable clients to discover network resources (printers, published shares, domain controllers) that are close to the physical location of the client, reducing network traffic over Wide Area Network (WAN) links.
Optimize replication between domain controllers.
Managing sites in Active Directory involves adding new subnet, site, and site link objects when the network grows, as well as configuring a schedule and cost for site links. You can modify the site link schedule, cost, or both, to optimize intersite replication. When conditions no longer require replication to a site, you can remove the site and associated objects from Active Directory.
Large hub-and-spoke topology management is beyond the scope of this documentation. For information about managing Active Directory branch office deployments that include more than 200 sites, see the "Active Directory Branch Office Guide Series" at https://www.microsoft.com/technet/archive/windows2000serv/technologies/activedirectory/deploy/adguide/default.mspx.
Using the SMTP intersite replication transport is beyond the scope of this documentation. For information about SMTP replication, see "Active Directory Replication" in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit and see the "Step-by-Step Guide to Setting up ISM-SMTP Replication." To download this guide, see the Active Directory link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.
Automatic site coverage is a default condition for Windows 2000 domain controllers. Operations and guidelines documented in this guide are consistent with the enabling of automatic site coverage.
The KCC and Replication Topology
The Knowledge Consistency Checker (KCC) uses site link configuration information to enable and optimize replication traffic by generating a least-cost replication topology. Within a site, for each directory partition, the KCC builds a ring topology that minimizes the number of hops between domain controllers. Between sites, the KCC creates a spanning tree of all intersite connections. Therefore, adding sites and domains increases the processing that is required by the KCC. Before adding to the site topology, be sure to consider the guidelines discussed in "Adding a New Site" later in this document.
Significant changes to site topology can affect domain controller hardware requirements. For more information about domain controller hardware requirements, see "Domain Controller Capacity Planning" in "Best Practice Active Directory Design for Managing Windows Networks." To download this guide, see the Active Directory link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.
Bridgehead Server Selection
By default, bridgehead servers are automatically selected by the intersite topology generator (ISTG) in each site. Alternatively, you can use Active Directory Sites and Services to select preferred bridgehead servers. However, it is recommended for Windows 2000 deployments that you donot select preferred bridgehead servers.
Selecting preferred bridgehead servers limits the bridgehead servers that the KCC can use to those that you have selected. If you use Active Directory Sites and Services to select any preferred bridgehead servers at all in a site, you must select as many as possible and you must select them for all domains that must be replicated to a different site. If you select preferred bridgehead servers for a domain and all preferred bridgehead servers for that domain become unavailable, replication of that domain to and from that site does not occur.
If you have selected one or more bridgehead servers, removing them from the bridgehead servers list restores the automatic selection functionality to the ISTG.
Site Management Tasks and Procedures
Table 1.21 shows the tasks and procedures for managing sites, as well as the tools and the recommended frequency for performing each task. After you configure sites, subnets, and site links for the initial deployment, most site management activity is limited to responding to changes in network conditions.
Table 1.21 Site Management Tasks and Procedures
Tasks |
Procedures |
Tools |
Frequency |
|---|---|---|---|
Add a new site. |
|
|
As needed |
Add a subnet to the network. |
|
|
As needed |
Link sites for replication. |
|
|
As needed |
Change site link properties. |
|
|
As needed |
Move a domain controller to a different site. |
|
|
As needed |
Remove a site. |
|
|
As needed |
Adding a New Site
Design teams or network architects might want to add sites as part of ongoing deployment. Although you typically create subnets to accommodate all address ranges in the network, you do not need to create sites for every location. Generally, sites are required for those locations that have domain controllers or other servers that run applications that depend on site topology, such as Distributed File System (DFS). When such locations are separated from other network locations by a WAN link, create a site object to optimize resource location, Active Directory replication, and domain controller location for clients.
When the need for a site arises, the design team typically provides details about the placement and configuration of site links for the new site, as well as subnet assignments or creation if subnets are needed.
KCC calculations for generating the intersite topology for a Windows 2000 forest can cause directory performance to suffer when the combined sites, site links, and domains exceed certain limits. When these limits are reached, follow the site administration guidelines on the Active Directory Branch Office Planning Guide link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.
As a general guideline, when any of the following conditions exist, consult your design team before adding a new site:
An existing site is directly connected to more than 20 sites.
A bridgehead server has more than 20 inbound connections.
The forest has 200 or more sites.
Procedures for Adding a New Site
Use the following procedures to add a new site. Procedures are explained in detail in the linked topics.
Create a site object and add it to an existing site link.
Associate a range of IP addresses with the site, as follows:
Create a subnet object or objects and associate them with the new site.
or
Create a site link object, if appropriate, and add the new site and at least one other site to the site link.
If, while performing procedure 1, you added the new site to an existing site link temporarily in order to create the site, remove the site from that site link.
Adding a Subnet to the Network
If a new range of IP addresses is added to the network, create a subnet object in Active Directory to correspond to the range of IP addresses. When you create a new subnet object, you must associated it with a site object. You can either associate the subnet with an existing site, or create a new site first and then create the subnet and associate it with the new site. If you are going to create a new site for the new network segment, see "Adding a New Site."
Procedures for Adding a Subnet
Use the following procedures to add a subnet. Procedures are explained in detail in the linked topics.
Obtain the network address and subnet mask for the new subnet.
Create a subnet object and associate it with the appropriate site.
Linking Sites for Replication
To link sites for replication, create a site link object in the IP transport container and add two or more sites to the link. Use a naming convention that includes the sites that you are linking. For example, if you want to link the site named Seattle to the site named Boston, you might name the site link SEA-BOS.
After you add two or more site names to a site link object, the bridgehead servers in the respective sites replicate between the sites according to the replication schedule, cost, and interval settings on the site link object. For information about modifying the default settings, see "Changing Site Link Properties."
At least two sites must exist when you create a site link. If you are adding a site link to connect a new site to an existing site, create the new site first and then create the site link. For information about creating a site, see "Adding a New Site."
Procedures for Creating a Site Link
Use the following procedures to link sites for replication. Procedures are explained in detail in the linked topics.
Determine the names of the sites you are linking.
Create a site link object in the IP container and add the appropriate sites to it.
Generate the intersite topology. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate replication topology generation immediately, use the following procedures to refresh the intersite topology:
Changing Site Link Properties
To control which sites replicate directly with each other and when, use the cost, schedule, and interval properties on the site link object.
These settings control intersite replication as follows:
Schedule: The time during which replication can occur (the default setting allows replication at all times).
Interval: The number of minutes between replication polling by intersite replication partners within the open schedule window (default is every 180 minutes).
Cost: The relative priority of the link (default is 100). Lower relative cost increases the priority of the link over other higher-cost links.
Consult your design documentation for information about values to set for site link properties.
Procedures for Configuring Site Links
Use the following procedures to configure a site link. Procedures are explained in detail in the linked topics.
Configure the site link schedule to identify times during which intersite replication can occur.
Configure the site link interval to identify how often replication polling can occur during the schedule window.
Configure the site link cost to establish a priority for replication routing.
Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate intersite replication topology generation immediately, use the following procedures to refresh the topology:
Moving a Domain Controller to a Different Site
If you change the IP address or the subnet-to-site association of a domain controller after Active Directory is installed on the server, the server object does not change sites automatically. You must move it to the new site manually. When you move the server object, the Net Logon service on the domain controller registers DNS SRV resource records for the appropriate site.
TCP/IP Settings
When you move a domain controller to a different site, if an IP address of the domain controller is statically configured, then you must change the TCP/IP settings accordingly. The IP address of the domain controller must map to a subnet object that is associated with the site to which you are moving the domain controller. If the IP address of a domain controller does not match the site in which the server object appears, the domain controller must communicate over a potentially slow WAN link to locate resources rather than locating resources in its own site.
Prior to moving the domain controller, ensure that the following TCP/IP client values are appropriate for the new location:
IP address, including the subnet mask and default gateway.
DNS server addresses.
WINS server addresses (if appropriate).
If the domain controller that you are moving is a DNS server, you must also:
Change the TCP/IP settings on any clients that have static references to the domain controller as the preferred or alternate DNS server.
Determine whether the parent DNS zone of any zone that is hosted by this DNS server contains a delegation to this DNS server. If yes, update the IP address in all such delegations. For information about creating DNS delegations, see "Performing Active Directory Post-Installation Tasks."
Preferred Bridgehead Server Status
Before moving any server object, check the server object to see whether it is acting as a preferred bridgehead server for the site. This condition has ISTG implications in both sites, as follows:
Site to which you are moving the server: If you move a preferred bridgehead server to a different site, it becomes a preferred bridgehead server in the new site. If preferred bridgehead servers are not currently in use in this site, the ISTG behavior in this site changes to support preferred bridgehead servers. For this reason, you must either configure the server to not be a preferred bridgehead server (recommended), or select additional preferred bridgehead servers in the site (not recommended).
Site from which you are moving the server: If the server is the last preferred bridgehead server in the original site for its domain, and if other domain controllers for the domain are in the site, the ISTG selects a bridgehead server for the domain. If you use preferred bridgehead servers, always select more than one server as preferred bridgehead server for the domain. If after the removal of this domain controller from the site multiple domain controllers remain that are hosting the same domain and only one of them is configured as a preferred bridgehead server, either configure the server to not be a preferred bridgehead server (recommended), or select additional preferred bridgehead servers hosting the same domain in the site (not recommended).
Note: If you select preferred bridgehead servers and all selected preferred bridgehead servers for a domain are unavailable in the site, the ISTG does not select a new bridgehead server. In this case, replication of this domain to and from other sites does not occur. However, if no preferred bridgehead server is selected for a domain or transport (through administrator error or as the result of moving the only preferred bridgehead server to a different site), the ISTG automatically selects a preferred bridgehead server for the domain and replication proceeds as scheduled.
Procedures for Moving a Domain Controller to a Different Site
Use the following procedures to move a domain controller to a different site. Procedures are explained in detail in the linked topics.
Change the static IP address of the domain controller. This procedure includes changing all appropriate TCP/IP values, including preferred and alternate DNS servers, as well as WINS servers (if appropriate). Obtain these values from the design team.
Create a delegation for the domain controller, if appropriate. If the parent DNS zone of any zone that is hosted by this DNS server contains a delegation to this DNS server, use this procedure to update the IP address in all such delegations.
Verify that the IP address maps to a subnet and determine the site association to ensure that the subnet is associated with the site to which you are moving the server object.
Determine whether the server is a preferred bridgehead server.
If the server is a preferred bridgehead server in the current site and you do not want the server to be a preferred bridgehead server in the new site, configure the server to not be a preferred bridgehead server.
Removing a Site
If domain controllers are no longer needed in a network location, you can remove them from the site and then delete the site object. Before deleting the site, you must remove domain controllers from the site either by removing it entirely or by moving it to a new location.
To remove the domain controller, remove Active Directory from the server and then delete the server object from the site in Active Directory. For information about removing a domain controller, see "Decommissioning a Domain Controller."
To retain the domain controller in a different location, move the domain controller to a different site and then move the server object to the respective site in Active Directory. For information about moving a domain controller, see "Moving a Domain Controller to a Different Site."
Domain controllers can host other applications that depend on site topology and publish objects as child objects of the respective server object. For example, when MOM or Message Queuing are running on a domain controller, these applications create child objects beneath the server object. In addition, a Message Queuing server that is not a domain controller and is configured to be a Message Queuing Routing Server creates a server object in the Sites container. Removing the application from the server automatically removes the child object below the respective server object. However, the server object is not removed automatically.
When all applications have been removed from the server (no child objects appear beneath the server object), you can remove the server object. After the application is removed from the server, a replication cycle might be required before child objects are no longer visible below the server object.
After you delete or move the server objects but before you delete the site object, reconcile the following objects:
Subnet object or objects for the site IP addresses:
If the addresses are being reassigned to a different site, associate the subnet object or objects with that site. Any clients using the addresses for the decommissioned site will thereafter be assigned automatically to the other site.
If the IP addresses will no longer be used on the network, delete the corresponding subnet object or objects.
Site link object or objects. You might need to delete a site link object, as follows:
If the site you are removing is added to a site link containing only two sites, delete the site link object.
If the site you are removing is added to a site link that contains more than two sites, do not delete this site link object.
Before deleting a site, obtain instructions from the design team for reconnecting any other sites that might be disconnected from the topology by removing this site. If the site you are removing is added to more than one site link, it might be an interim site between other sites that are added to this site link. Deleting the site might disconnect the outer sites from each other. In this case, the site links must be reconciled according to the instructions of the design team.
Procedures for Removing a Site
Use the following procedures to remove a site. Procedures are explained in detail in the linked topics.
Determine whether the server object has child objects. If a child object appears, do not delete the server object. If a domain controller has been decommissioned and one or more child objects appears below the server object, replication might not have completed. If replication has completed and child objects exist, do not delete the server object. Contact a supervisor.
Delete the server objects within the Servers container of the site that you are removing.
Delete the site link object, if appropriate. Obtain this information from the design team.
Associate the subnet or subnets with the appropriate site, if appropriate. If you no longer want to use the IP addresses associated with the subnet object or objects, delete the subnet objects. Obtain this information from the design team.
Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate intersite replication topology generation immediately, use the following procedures to refresh the topology: