Method 2: DNS priority. Another way to ensure that spoke sites fail back to the hub rather than to other spokes is to manipulate the DNS priority of a DC's SRV record. A component of the SRV record, the priority is an arbitrary number, and a lower number equates to a higher priority. By default, a DC's DNS priority is zero. All other factors being equal, DCs with a lower priority number will appear higher on the DC list than DCs with a higher priority number. As a result, you can use an SRV record's priority field to influence the DC list.
Figure 4 shows our hub-and-spoke example with SRV priorities added. The Hub site DCs have a high priority of 10, while the Spoke1, Spoke2, and Spoke3 sites have a lower priority of 20. Because these priorities influence the DC list, the high-priority Hub site DCs always appear ahead of the low-priority Spoke2 and Spoke3 site DCs. Although the DC in the client's site (Spoke1) is also a low priority, the Spoke1 DC appears ahead of the high-priority Hub DCs in the DC list because the DCs in a client's site always appear before all other DCs in the list. To control the priority field of a DC's SRV record, you must add the LdapSrvPriority registry value of type REG_DWORD to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey. Note that all DCs in a site should have the same priority to ensure that they receive the same treatment in the DC list.
Method 3: Sister-site forced coverage. The sister-site method, which you can combine with the previous two methods, lets you create a two-stage DC failover for more complex topologies. For example, as Figure 5 shows, the Spoke1 and Spoke3 sites are physically close to each other and connected by a high-bandwidth WAN circuit. A low-bandwidth circuit connects the Hub site to the Spoke3 site. (For simplicity's sake, I've left the Spoke2 site out of the example, but I've left its DC in the DC list.) This topology is common for US companies operating in the Asia Pacific region, where two nearby locations will connect to each other over a high-bandwidth circuit but connect to North America over a relatively low-bandwidth circuit.
In this situation, failover needs to occur to a nearby sister site first and occur to a hub site in the United States only if the sister site is unavailable. To design this type of failover, use the SiteCoverage registry key to assign a DC to be part of a site. Before you begin, you must determine how you'll prevent clients from choosing the covering DC (which is at a different location and presumably slower to respond) as often as they choose the local DCs—from the client's point of view, both DCs are in the client's site and are therefore equally desirable. The answer is to use DNS priority to make the sister site's DCs slightly less desirable than the local DC by setting the DNS priority of Spoke1 to 15 and setting the DNS priority of sister site Spoke3 to 20. This configuration ensures the local DC will always appear first in the onsite DC section of the DC list.
Let's walk through a DC failover scenario to test the configuration. When all DCs are available, Client1 will always choose SPOKE1-DC1 because it's on site and has the highest priority. If SPOKE1-DC1 isn't available, Client1 will next choose either SPOKE3-DC1 or SPOKE3-DC2 because the client views them as being on site; their lower priority doesn't matter because the higher-priority SPOKE1-DC1 is unavailable. If both SPOKE1-DC and the Spoke3 DCs are unavailable, Client1 will choose one of the Hub site DCs because they have the lowest priority of the domainwide DCs available. If both Spoke1 and Spoke3 are unavailable, I think Client1 will have bigger problems to worry about.
This sister site method provides a robust and multilayered DC failover capability for many kinds of site topologies. The downside to this design, however, is that it's complex to configure, complicated to maintain, and difficult to explain.
Addressing Other Considerations
In addition to the methods I've described previously, you need to consider other factors that can influence DC selection when you're designing DC failover. The AutoSiteCoverage and GcSiteCoverage registry entries and the DNS weight of a DC's SRV record can all affect DC selection performance.
AutoSiteCoverage. If you create DC-less sites to support various site-aware applications such as DFS, you can consider disabling the AutoSiteCoverage registry entry of type REG_DWORD by setting it to 0 for your other spoke DCs. (This entry is located under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey.) This recommendation is based on the premise that authenticating from a spoke to the hub is almost always better than authenticating from one spoke to another spoke (the exception being a sister-site scenario). If you disable the AutoSiteCoverage setting in the spokes only, the hub's AutoSiteCoverage will cover the DC-less spoke and prevent another spoke from trying to cover it. If you've configured a sister-site network topology, also disable AutoSiteCoverage on the hub's DCs and manually configure site coverage where necessary.
GcSiteCoverage. Just as you can use the AutoSiteCoverage registry key to force a DC to cover a site, you can set the GcSiteCoverage registry entry of type REG_DWORD to 1 to ensure that clients fail over to the appropriate GC server. This entry is located under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey.
DNS weight. Another field in a DC's SRV record that you can use to influence DC selection is the DNS weight. Weighting helps to order the DNS priority list within a given priority; a higher DNS weighted number means that the DC will be higher on the list than other DCs that have the same priority but have a lower DNS weight. The DNS weight default value is 100. For example, if HUB-DC2 was significantly more powerful than HUB-DC1 and HUB-DC3, you might give HUB-DC2 a weight of 150 so that it would always appear at the top of the Hub DCs in the list. Be aware that unless you have widely varying types of hardware for your DCs, DNS weighting adds yet another layer of manual administration to an already complicated site topology with little benefit. Just because you can doesn't mean you should.
Taking Control of Your DCs
A basic AD site topology provides many benefits, but a consistent and predictable client choice of an alternate DC isn't one of them. Until the Windows server OS has a DC locator process that uses site costing to help with DC selection, you'll have to establish the DC failover order yourself. Once you understand how to use the techniques in this article to influence the list of DCs, you can be sure your users will continue to have the best available service during any DC outages.
End of Article
Prev. page
1
2
[3]
next page -->
