Determine which domain controller (Logon Server) you have authenticated against.

In some cases, you need to determine which domain controller you are authenticated against (your logonserver). This can come in handy for Group Policy enforcement issues where users complain about slow logins. A user can authenticate to the wrong DC because the nearest DC is not available, access is blocked by a firewall, subnets and sites are misconfigured in Active Directory, or DNS issues. As a result, the user can get all GPOs, scripts, etc., not from the nearest domain controller, but from any other DC. This can result in long GPOs, slow program installations, slow loading of roaming profiles, or files in redirected folders.

How to find out on which domain controller you are logged in?

You can find out the domain controller through which you logged on to the domain in several ways:

• From the command line: set log

LOGONSERVER=\\MSK-DC02

• From the command results: systeminfo | find /i “logon server”

• From a variable environment: echo %logonserver%
• You can also get the value of an environment variable using PowerShell: $env:LOGONSERVER

• In the output of the gpresult /r command:

Group Policy was applied from: DC02

The nltest utility shows the domain controller that the computer authenticated against at boot (logon server of the user and the computer can sometimes be different). Nltest also allows you to check the trust relationship between the computer and the domain controller and the name of the Active Directory site to which the DC belongs (Dc Site Name):

nltest /DSGETDC:site.io

If you are logged on to the computer with a local account, the LogonServer variable will contain the name of your computer instead of the name of the domain controller.

Knowing the domain controller, you can get various information about the user from the DC security logs (for example, the user's logon history to the domain and other logs).

You can automatically record information on which domain controller the user has authorized in the description of the computer in AD. This way you can find out the LogonServer for a specific computer from AD without accessing a specific computer over the network or locally.

How does Windows determine the nearest domain controller?

The NetLogon service is responsible for determining the LogonServer when Windows boots . It must be running: 

get-service netlogon

Simplified, the process of finding a domain controller by a Windows client looks like this:

• When Windows boots, the NetLogon service makes a DNS query for a list of domain controllers (SVR records _ldap._tcp.dc._msdcs.domain_ ;
• DNS returns a list of DCs in the domain;
• The client makes an LDAP query to the DC to determine the AD site by its IP address;
• DC returns the site that corresponds to the client's IP or the closest site (this information is cached in the registry branch HKLM\System\CurrentControlSet\Services\Netlogon\Parameters and is used at the next login for faster lookup);
• The client queries DNS for a list of domain controllers in the site (in the _ section tcp.sitename._sites...);

• Windows attempts to contact all DCs in the site and the first one to respond is used to perform authentication and as the LogonServer.

You can switch your computer to another AD domain controller manually with the command:

nltest /SC_RESET:WINITPRO\MSK-DC02.site.io

Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\MSK-DC02.site.io
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

If the specified DC is not available, an error will appear:

I_NetLogonControl failed: Status = 1311 0x51f ERROR_NO_LOGON_SERVERS

If none of the domain controllers is available, or the computer is disconnected from the network, then when the user logs in, the following message will appear:

There are currently no logon servers available to service the logon request. 

There are no servers that could process the request to enter the network.

You can only log on to such a computer with saved domain user credentials.

You can find the closest domain controller to you according to the hierarchy of sites, subnets, and weights using the Get-ADDomainController cmdlet from the Active Directory Module for PowerShell:

Get-ADDomainController -Discover -NextClosestSite

This way you can determine the name of the domain controller through which the computer should authenticate. If it differs from the current one, you need to understand why.