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 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
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:
- 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 LDAP
- Determine if the chosen DC is in the same site as the member
server, based on the information configured in AD Sites & Services
- If so, the member server begins using that DC for communications
- If not, the DC tells member server what site it is in
- Member server sends new DNS query for the list of DCs specifically in its own site
- Member server selects the first DC in DNS result list and connects to it via LDAP
- If no DC in the local site is available, connect to any DC in the domain
- Cache the name of the local site in the registry to speed up future operations
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 & 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