What happens if no DC in the client's site responds? In this (I hope rare) case, the client sticks with the original DC, which might be a long distance away.
Let's walk through a few concrete examples. Figure 2 shows a network with two sites: one in Scottsdale, Arizona, and one in Amsterdam, The Netherlands. Each site contains one DC: DCSC1 and DCAM1, respectively. DNSSC1 is the primary DNS server for the new workstation WSSC1. WSSC1 first queries its DNS server (i.e., DNSSC1) for any DC in the ds.megacorp.com domain, and DNS responds with SRV records for DCAM1 and DCSC1. WSSC1 then sends an AD ping over the WAN to DCAM1, which responds within 100 milliseconds (ms). DCAM1 returns the name of WSSC1's site (i.e., Scottsdale) and a flag indicating that DCAM1 isn't in the site closest to Scottsdale. WSSC1 queries DNSSC1 again, this time requesting DCs in the Scottsdale site. DNSSC1 returns the SRV record for DCSC1. WSSC1 sends an AD ping to DCSC1 and gets a reply that DCSC1 is in the site closest to WSSC1. WSSC1 authenticates with DCSC1 and stores its site name (i.e., Scottsdale) in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey's DynamicSiteName value. The next time WSSC1 authenticates, it automatically uses the site name in DynamicSiteName, speeding subsequent authentications.
Now, suppose that WSSC1 is a laptop and that the user travels to the Amsterdam office. When the user plugs the laptop into the Amsterdam network, the laptop receives a new IP address and a new DNS server from the local DHCP server. But this time the transactions look a little different. As Figure 3 shows, WSSC1 queries the DNS server DNSAM1 for DCs in the Scottsdale site because that site is recorded in the laptop's DynamicSiteName registry value. DNSAM1 returns specifics for DCSC1. WSSC1 sends an AD ping to DCSC1, which replies that it isn't in the site closest to WSCC1's site and that WSSC1's site is now Amsterdam. WSSC1 then queries DNSAM1 for DCs in the Amsterdam site and receives the answer DCAM1. WSSC1 sends an AD ping to DCAM1 and gets a reply that DCAM1 is in the site closest to WSSC1's site. WSSC1 authenticates with DCAM1 and stores the site name Amsterdam in the DynamicSiteName registry value.
What if all the DCs in a client's site are down or unresponsive? In this case, the client falls back to whichever DC provided its site information. This DC is typically in another site, which means that the client authenticates to and sets up a secure channel with a remote DC over the WAN—not good for performance. In such circumstances, the client's Netlogon process tries to rediscover a DC in the closest site whenever another attempt to authenticate to the domain occurs. You can set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey's CloseSiteTimeout value to the number of seconds that must elapse before Netlogon will attempt to rediscover its DC. The default value is 900 seconds (i.e., 15 minutes); Netlogon will accept values between 60 and 4,233,600 seconds (i.e., between 1 minute and 49 days).
Sometimes, you don't want an AD client to determine its site membership through the typical DC query. For example, suppose you have a member server with two NICs on different subnets. You can't specify which subnet the system belongs in simply by setting the DynamicSiteName registry value because Netlogon resets that entry. However, the client's Netlogon service does provide a way to bypass the site-membership calculation: Set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey's SiteName value to the name of the site that you want the client to be a member of. The SiteName value requires a string, so you need to enter a name such as Amsterdam. Of course, keep in mind that manually manipulating the registry can be risky; take appropriate precautions to back up your data before you attempt such manipulation.
Covering DC-less Sites
One of the best ways to reduce the complexity and increase the manageability of your AD deployment is to reduce the number of DCs. Each DC you add to your forest increases your hardware, software, and operating costs, not to mention replication latency and troubleshooting time. Satellite offices with good network connectivity and only a few users are great candidates to be DC-less sites.
You might ask, "Why not just add satellite office subnets to the main office site?" This question makes a lot of sense from an AD perspective: Clients would authenticate to DCs in the main office and, because no DC exists at the remote office, you'd have no replication-topology problems to deal with. But AD isn't the only application that relies on the proper definition of sites. For example, Microsoft Dfs, the technology upon which File Replication Service (FRS) is based, locates nearby servers according to AD site definitions. If the satellite office has a Dfs server, you wouldn't want to collapse a satellite site into the main office site.
Suppose you have a small branch office with 30 employees and a reliable T1 connection to the main office. You have no reason to put a DC in the branch location because the network can easily support the authentication and lookup traffic that 30 workstations generate. But which DC will the branch-office clients use to authenticate? The answer lies in the notion of site coverage. DCs publish both generic and site-specific SRV records so that clients can find a DC anywhere in the domain or in a specific site. But by default, DCs also publish site-specific SRV records for nearby sites that have no DCs. This way, a client can use a site-specific DNS query to locate a DC even when no DCs exist in the client's site.
The rules for determining which DC will cover a DC-less site are fairly straightforward. When each DC starts up, it looks in its copy of AD for any DC-less sites. For each DC-less site, the DC determines whether its own site is closest to the DC-less site, which the site-link cost information in AD determines. If the DC's site is closest, the DC publishes site-specific SRV records for that DC-less site. If the DC determines that more than one site shares the lowest site-link cost value, the DC compares the number of DCs in its site with the number of DCs in the other sites. If the DC's site has the most DCs, the DC publishes site-specific SRV records for the DC-less site. Having the site with the most DCs cover the DC-less site provides more DCs to share the load of the DC-less site. If the sites have the same number of DCs, the site that comes first alphabetically covers the DC-less site.
Register
