Domain Controller Selection

The 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 Matters

Windows will optimize connections to the best available domain controller for the following types of situations:

• Authentication for users logging directly into the server
• Authentication for users accessing the applications on the server (such as SharePoint or Exchange)
• Group policy processing for user accounts and the computer account
• Promotion of a member server to a DC

For 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 Works

When a member server or workstation needs to find a domain controller, it goes through the following steps:

1. Query the primary DNS server for the all domain controller SRV records in the domain (These have the format of "_ldap._tcp.mydomain.local")
   1. 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:
      
2. Select the first DC in DNS result list and connect to it via LDAP
3. Determine if the chosen DC is in the same site as the member server, based on the information configured in AD Sites & Services
   1. If so, the member server begins using that DC for communications
   2. If not, the DC tells member server what site it is in
      1. Member server sends new DNS query for the list of DCs specifically in its own site
      2. Member server selects the first DC in DNS result list and connects to it via LDAP
      3. If no DC in the local site is available, connect to any DC in the domain
4. Cache the name of the local site in the registry to speed up future operations

If 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 Help

To 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.

 

 

Configuration

How 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 & Services
• Each of those subnets is configured for the correct AD Site
• Each site with a significant number of clients has a local DC to authenticate with

If 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.