Having all the DCs in a covering site cover the DC-less site has a downside. Each DC in the covering site publishes SRV records for the DC-less site, so a covering site with 5 DCs and 2 GCs will generate an additional 32 SRV records (4 site-specific SRV records per DC and an additional 2 records for each DC that's also a GC). If you have a hub-and-spoke topology with 25 DC-less satellite sites connected to one hub, and you have 25 DCs and 7 GCs in the hub, you'll get a whopping 3550 additional SRV records per domain.
Now consider that each DC is busy republishing its SRV records every hour. (This schedule is the default in Win2K; DCs republish their SRV records every 15 minutes in Windows Server 2003.) You can imagine the kind of network traffic these site-coverage SRV records will generate. And if you have AD-integrated DNS zones, you'll be faced with a significant amount of additional replication traffic going to each DC in the domain. Furthermore, AD stores SRV records with the same name in a multivalued attribute of one AD object. Because of attribute size limitations, AD-integrated zones can handle only about 800 SRV records with the same name. A large branch office could easily exceed this limit.
Thankfully, Win2K Service Pack 2 (SP2) and later provide a way to control site coverage through registry settings. First, you can disable automatic site coverage on the DC. To do so, set the system's HKEY_LOCAL_MACHINE\SYSTEM\CurrentCon-trolSet\Services\Netlogon\Parameters registry subkey's AutoSiteCoverage value to 0. Second, you can explicitly name the sites that a DC will cover. To do so, set the system's HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters subkey's SiteCoverage value to the list of sites to cover (use the sites' relative distinguished names—RDNs—separated by spaces). Setting this value forces the DC to publish SRV records for the named sites, whether or not those sites already contain DCs. You can set the subkey's GcSiteCoverage value in the same way to control the publication of site-specific GC locator records. You can use these registry settings to assign specific DCs in a hub site to service authentications from DC-less satellite sites. This process reduces the number of SRV records added to DNS and makes the system more manageable.
You have one other option to reduce the number of DNS records in your environment. Each DC that hosts an AD-integrated DNS zone publishes a Name Server (NS) record for the domain. DNS uses this record to find authoritative name servers for the zone. If you have many DCs in your domain, you'll get many NS records. To prevent the DNS service from publishing its NS record, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters registry subkey's DisableNSRecordsAutoCreation value to 1.
The effect of disabling the publication of NS records is subtle. When a server receives a direct query (e.g., from a client that lists the server as the primary resolver), its DNS service properly resolves names in the zone. But because no NS record exists for the server, other DNS servers, processing recursive queries, won't identify the server as a name server for the domain and won't pass queries to it. For more information about this process, see the Microsoft article "Problems with Many Domain Controllers with Active Directory Integrated DNS Zones" (http://support.microsoft.com/?kbid=267855).
Controlling DC Failovers and Loads
I've shown how you can control which DCs will cover DC-less sites, but what about controlling how the clients within a site use DCs? The answer involves the AD ping process that I described earlier.
Internet Engineering Task Force (IETF) Request for Comments (RFC) 2782 specifies two numeric values—priority and weight—associated with each SRV record. These values control which of several possible candidates the client should select.
SRV priority. The SRV selection rules in RFC 2782 state that clients must first attempt to connect to those hosts with the lowest-priority SRV records and attempt to connect to hosts with higher-valued priorities only when unable to connect to a host with a lower priority. This rule provides multileveled failover for crucial services: Simply set the priority of your primary hosts to 0 and set a higher priority for your backup hosts. By default, all DCs publish their SRV records with a priority of 0. To override this value, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey's LdapSrvPriority value to a higher number. The DC will use this value in its _ldap SRV records' priority field.
Consider the example that Figure 4 shows. You have two DCs—DC1 and DC2—in the same site, and you want to make sure that DC2 is used only as a failover when DC1 is unavailable. You can set the priority on DC1 to 0 and the priority on DC2 to 10 (the exact value isn't important so long as it's greater than 0). Clients will select DC2 only when DC1 doesn't respond to an AD ping request within 100ms—a situation that likely will occur only when DC1 is down or extraordinarily busy.
Register
