/ Insights / Domain Controller Selection Insights Domain Controller Selection May 17, 2018 ConcurrencyThe process of a Windows client selecting an Active Directory domain controller isn’t too complex but is often not fully understood. Let’s look at the way a member server chooses a DC and how this affects applications.Why it MattersWindows will optimize connections to the best available domain controller for the following types of situations:Authentication for users logging directly into the serverAuthentication for users accessing the applications on the server (such as SharePoint or Exchange)Group policy processing for user accounts and the computer accountPromotion of a member server to a DCFor each of these, it is clearly important to try to use a DC that is local to the member server. For example, you wouldn’t want thousands of Exchange authentications to be sent to a DC across the country if a local one is available.How it WorksWhen a member server or workstation needs to find a domain controller, it goes through the following steps:Query the primary DNS server for the all domain controller SRV records in the domain (These have the format of “_ldap._tcp.mydomain.local”)This will return an entry for each DC in the domain. For example, this screenshot shows the lookup result for a domain with 2 DCs, named MGLABDC4 and MGLABDC5:Select the first DC in DNS result list and connect to it via LDAPDetermine if the chosen DC is in the same site as the member server, based on the information configured in AD Sites & ServicesIf so, the member server begins using that DC for communicationsIf not, the DC tells member server what site it is inMember server sends new DNS query for the list of DCs specifically in its own siteMember server selects the first DC in DNS result list and connects to it via LDAPIf no DC in the local site is available, connect to any DC in the domainCache the name of the local site in the registry to speed up future operationsIf the client attempts to contact a DC that’s offline, it will try to contact the next one in the list until all results are exhausted. Here is a screenshot from a member server showing how the server is preferring the DC in its local site. A common misconception is that Windows clients will use their configured DNS servers as their primary DCs. As you can see by the above process, this is not the case. The member server will query its configured DNS server to retrieve a list of DCs and then intelligently choose the correct DC based on the site information.Commands to HelpTo help view and diagnose how a member server is locating its DC, try the following commands echo %logonserver% – This shows the DC that was used to authenticate and log in the current user nltest /dsgetsite – This shows the AD site that the current server has detected that it’s in nltest /dclist: (include the colon at the end) – This shows the list of DCs in the current domain, including which site each is in. In this example, MGLABDC4 is in the MG-AZ-EASTUS site, and MGLABDC5 is in the MG-AZ-EASTUS2 site. nslookup -type=srv _ldap._tcp.mydomain.local. – This will query the primary DNS server for all domain controller SRV records. This should return all of the DCs in the domain. In this example, MGLABDC4 and MGLABDC5 are returned. nslookup -type=srv _ldap._tcp.mysitename._sites.dc._msdcs.mydomain.local. – This will query the primary DNS server for domain controllers that are registered in “mysitename”. In this example, only MGLABDC4 is in the site that was queried, which matches the information we found with nltest /dclist: previously.ConfigurationHow do you ensure that all of this happens smoothly? The single most important thing to check is that AD Sites & Services is configured correctly. You should review and confirm the following points:All of the LAN subnets in the corporate network are defined in AD Sites & ServicesEach of those subnets is configured for the correct AD SiteEach site with a significant number of clients has a local DC to authenticate withIf the Windows client’s IP address doesn’t match to a subnet defined in the AD configuration, it has no way of finding a the closest DC. That can lead to unoptimized connections and slower logons and AD operations. For more information, see this article on Technet or this Microsoft KB article.