Share via

How Domain Controllers are Located in Windows

  • Article

Introduction

Using an efficient and reliable Domain Controller localization process is important for AD-integrated systems and applications in order to avoid slowness when processing AD-related operations and to maintain the high availability of AD services. This Wiki article explains the importance of having an efficient localization process and focuses on the DC Locator process used on Windows systems.

Why is it important to have an efficient Domain Controller localization process

Having an efficient Domain Controller localization process is important because:

  • Sites are often linked by slow network connections which might cause slowness with cross-site communication with Active Directory
  • It minimizes the impacts when a Domain Controller is not available
  • It reduces unnecessary network traffic between sites by locating the closest Domain Controller

 

Imagine the situation where CONTOSO is a company having two sites (Redmond and Denver) with two Domain Controllers per site for high availability of AD services. CONTOSO has an AD-Integrated application hosted in Redmond. CONTOSO application is a mission critical application where a downtime causes huge Business impacts and loss. CONTOSO developers worked then on introducing an automatic Domain Controller localization process and LDAP pings to periodically check the health status of the queried Domain Controller. The localization is done by querying the domain DNS name contoso.com A records and using the first available Domain Controller.

With this implementation, CONTOSO developers noticed that:

  • The communication with Active Directory is randomly slow
  • Significant LDAP traffic is passing through Redmond-Denver WAN connection when the slowness is detected
  • The application is able to automatically locate a Domain Controller and switch to another one when the used Domain Controller becomes not available

CONTOSO developers were then able to ensure the high availability of the communication between the application and Active Directory by implementing a detection of failures and automatic localization of a new Domain Controller. However, this is not enough as the used localization process needs to locate the closest Domain Controller to avoid slowness due to communicating Domain Controllers over WAN connection while it is possible to avoid it.

The localization process should then identify DC1 or DC2 to be used by the application if they are available. If not, it should identify DC3 or DC4 to be used. With this approach CONTOSO developers will ensure that the application has a high available communication with AD with no slowness when Redmond Domain Controllers are available. The slowness will then be noticed only when all Domain Controllers in Redmond are no longer available as Domain Controllers in Denver will be used instead in this case for the continuity of the service.

By using the DC Locator process (described in the next chapter), CONTOSO will be able to have a reliable localization process and fully achieve their requirements.

How is DC Locator process working

DC Locator process is used by Windows systems to locate the closest available Domain Controller within an AD Domain. It relies on DNS resolution and AD sites and subnets configuration for the identification. When an AD-integrated Windows computer starts, the following will be done to locate the closest Domain Controller:

  • The Windows computer sends an DNS query to ask for DNS resolution of **_ldap._tcp.dc._msdcs.**domain.com (Example: _ldap._tcp.dc._msdcs.contoso.com) SRV records

  • The DNS server responds with the list of registered DNS records (The records contain the list of Domain Controllers within the AD domain)

  • The Windows computer reviews the list of SRV records and selects one according to the priority and weight assigned to the records. It will then query the DNS server to get the IP address of the selected Domain Controller

  • The DNS server checks the A record of the Domain Controller and responds with the IP address

  • The Windows computer contacts the selected Domain Controller and initiates the communication with it

When the communication is initiated, the selected Domain Controller will check that the client computer belongs to its Active Directory site. This is done by comparing the IP address of the client computers with Active Directory configured sites and subnets. Here, there will be two possible scenarios:

  • The Windows computer and the selected Domain Controller belong to the same Active Directory site: In this situation, the following will happen:
    • The selected Domain Controller provides the client computer with the site name

  • The Windows computer caches the name of its AD site and the name of the used Domain Controller. The selected Domain Controller will be used as long as it is available. The Windows computer no longer needs to re-do the localization process each time it needs to communicate with a Domain Controller.
  • The Windows computer and the selected Domain Controller do not belong to the same Active Directory site: In this situation, the following will happen:
    • The selected Domain Controller provides the client computer with the site name and informs it that it is not the closest Domain Controller

  • The Windows computer sends a DNS query to ask for DNS resolution of ldap._tcp.Computer_Site_Name._sites.dc._msdcs.domain.com (Example: _ldap._tcp.denver._sites.dc._msdcs.contoso.com) SRV records

  • The DNS server responds with the list of registered DNS records (The records contain the list of Domain Controllers within the AD site)

  • The Windows computer reviews the list of SRV records and selects one according to the priority and weight assigned to the records. It will then query the DNS server to get the IP address of the selected Domain Controller

  • The DNS server checks the A record of the Domain Controller and responds with the IP address

  • The Windows computer contacts the selected Domain Controller and initiates the communication with it

Remark 1: If the Windows computer fails to communicate with a selected Domain Controller, it will try to contact another one according to the priority and weight assigned to the SRV records.

Remark 2: If a Windows computer already has its AD site cached and would like to localize a new Domain Controller (Example: The current Domain Controller in use is no longer available) then it will start directly with Step number 7 (We refer to the steps shown in the previous figure)

Remark 3: The Windows computer AD site is stored in the following registry entry: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName

 

By using the described process, a Windows computer has the “intelligence” to locate the closest Domain Controller when it needs to communicate with Active Directory. However, this process will work efficiently only if Active Directory Sites and Subnets are maintained properly.

Can DC Locator Process be used by third party applications

Yes, Microsoft DsGetDcName API can be used: http://msdn.microsoft.com/en-us/library/ms675983(v=vs.85).aspx

Conclusion

This Wiki article shared the importance of locating closest Domain Controllers by AD-integrated applications and systems and how DC Locator process works. Using DC Locator or a similar process is important for AD-integrated systems and applications to minimize downtime and performance issues. Microsoft provide DsGetDcName API that can be used for the localization which is already used by Windows systems themselves.