Sites and the New Knowledge Consistency Checker

The Knowledge Consistency Checker and the Inter-Site Topology generator work together to determine the most efficient way to replicate information across the forest and within sites. These programs determine replication paths for both Active Directory replications and file replication. When a forest is upgraded to the Windows Server 2003 functional level, the new Windows Server 2003 spanning tree algorithm is enabled. This updated algorithm allows for improvements in both efficiency and scalability. For example, Windows 2000 spanning tree algorithm allowed one domain to contain up to 300 sites. The new Windows Server 2003 algorithm allows one domain to have up to 3,000 sites. The Windows Server 2003 algorithm uses a randomized selection process for bridgehead server selection via the inter-site topology generator. This process allows for more evenly distributed bridgehead replication workload among domain controllers in a site. The result is improved efficiency that only gets better as additional domain controllers are added to a site. The default behavior is for this randomized selection process to occur only when new connection objects are created in a site. Optionally, a Windows Resource Kit tool, called adlb.exe, can be run to redistribute the load each time changes occur in the topology or when the number of domain controllers in the site changes. In addition, adlb.exe can stagger the replication schedules so that the outbound replication load for each server is spread out more evenly across time.

Summarizing Sites

In Active Directory, a site is a group of computers that are connected by 10MB or faster connections. The easiest way to look at this is any LAN separated by a WAN link is more often than not a site. Sites and subnets are used by Active Directory to find the " closest " object of a particular type. This could be a printer, a DFS replica or a domain controller. In some environments, it is not necessary to follow the strict definition of sites. If a site will never have a domain controller it will always be adopted by another domain controller. As such, by summarizing sites you can ensure that certain locations are serviced by a particular domain controller. As the number of domains and sites grows it is harder and harder for the Knowledge Consistency Checker (KCC) to maintain the topology. By reducing the number of sites you can lower the load on the KCC and leverage it longer as the environment grows.

As an example, let's say that CompanyABC has 40 small sites in Japan and 50 small sites in the United States. Each site consists of a single subnet. The largest office in Japan is in Tokyo. It has a pair of domain controllers. The largest site in the U.S. is in San Jose. It has two domain controllers as well. The two choices would be to either create 90 sites, 90 subnets, and 90 site links or create two sites, 90 subnets, and two site links.

If all 90 sites were defined, the KCC would process site link costs for all 90 site links to determine which Domain Controllers should adopt which sites. DNS would hold site records for all 90 sites to list _gc, _ldap, and _kerberos SRV records. If the Domain Controllers in Tokyo happened to be busy when the KCC was processing links, sites in Japan could be adopted by the DCs in San Jose and WAN traffic would increase as authentication, login scripts, and GPO application happened across the WAN.

Simplification of Site Management via Site Summarization Could Backfire

The simplification of site management via site summarization could backfire if you plan to implement distributed technologies that are based on Active Directory sites. SMS 2003 is an example of this. If each location were to get its own distribution server, which was previously managed by SMS Sites in SMS 2.0, and if the sites were summarized into two sites, there would be a very good chance that client machines would go to the wrong distribution server; their local site would not exist in SMS 2003. SMS 2003 eliminates its own Site database and leverages the Sites and Subnets area of Active Directory.

If, on the other hand, the sites were summarized into only two sites, each holding the appropriate subnets, the KCC would perform much less work and sites could not be adopted by the wrong domain controllers as they would have local domain controllers. The DNS structure would be greatly simplified and administrative tasks would be reduced.

Site Adoption

Site adoption occurs when a site is defined and it contains no domain controllers. Messages will appear in the event viewer such as " Site 'siteB' does not have any Domain Controllers for domain 'CompanyABC'. Domain Controllers in site 'closest_site' have been automatically selected to cover site 'siteB' for domain 'CompanyABC' based on configured Directory Server replication costs." . At the same time, the _sites records in DNS will populate with the new site and records pointing to the DCs in the site that adopted the site in question.

The Directory Server replication cost refers to the cost associated with the site links traversed to get from one site to another. These values default to a cost of 100 but can be manually configured to further control site adoption. This can be especially useful with multihub and spoke replication topologies where you want everyone's second choice of DCs to be a particular site.

To set the cost on a site link follow these steps:

1. Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services.

2. Expand Sites.

3. Expand Intersite Transports.

4. Click IP and right-click the site link in the right column.

5. Select Properties.

The cost of the site link and the replication schedule can be modified here.

Controlling Site Authentication Using DNS

Another way to control authentication for a particular site via a specific domain controller or group of domain controllers is through DNS. By maintaining DNS manually, specific records can be placed in _dc/_sites/_site in question/_tcp for the following:

• _kerberos SRV

• _ldap SRV

Use Manual Control of DNS as a Last Resort

Although disabling dynamic updates to DNS gives you greater control over DNS it also results in greatly increased administration of DNS. You should use manual control of DNS as a last resort to control authentication choices of hosts .

This forces the hosts in the site to always use a particular DC as their first choice for authentication. This can be useful if local DCs are to be dedicated to an application that places a very high load on the DC for either authentication or LDAP queries. To enable manual control of DNS, simply disable dynamic updates on the DNS zone. If the DNS is Windows 2003 DNS this can be accomplished by the following:

1. Choose Start, All Programs, Administrative Tools, DNS.

2. Expand the DNS server.

3. Expand Forward Lookup Zones.

4. Right-click the zone for which dynamics updates are to be disabled and click Properties.

5. In the drop-down menu for Dynamic Updates, change the dynamic updates option to None.

6. Click OK to finish and close the Properties dialog.