How to find your logon server/ Domain Controller you are authenticated to

If you manage an Active Directory environment with more than one domain controller, sooner or later you’ll need to find your logon server and answer a simple question: which domain controller is this computer actually using? The quick answer is:

cmd

echo %LOGONSERVER%

That returns something like \\Server-DC2, which is the domain controller recorded for the interactive logon session. But there’s an important catch: it isn’t a live query of Active Directory. If you’re troubleshooting slow logons, Group Policy, authentication, drive mappings or a domain connectivity problem, you often need to know more than the value stored in %LOGONSERVER%. The commands below answer different questions, which is why they can legitimately return different domain controllers.

The short answer: %LOGONSERVER%

From Command Prompt, use either of these:

cmd

echo %LOGONSERVER%
set logonserver

You’ll sometimes see set l suggested, but I wouldn’t use it in a troubleshooting guide. It lists every environment variable beginning with L, so set logonserver is much more explicit. From PowerShell:

powershell

$env:LOGONSERVER

%LOGONSERVER% is an environment variable populated during logon, holding the domain controller associated with the interactive logon. That means it can go stale. If a user logged on at 8am with FP-DC2 as their logon server, %LOGONSERVER% can still show FP-DC2 hours later, even if the client is now using another domain controller for later operations.

It also doesn’t prove the machine contacted a domain controller during the current logon at all, because Windows can use cached domain credentials when no DC is available. So %LOGONSERVER% is useful, but it’s only one piece of the picture.

Before you start: run nltest from an elevated prompt

Most of the commands below use nltest. Microsoft’s nltest command reference says to run it from an elevated command prompt, so start there. nltest is included in current Windows client and server releases. If nltest.exe is missing on a particular workstation, install the RSAT AD DS tools, or run the checks from a machine that has them.

Why the commands can disagree

This is where Active Directory troubleshooting gets interesting. These five commands aren’t five ways of asking the same question:

They look at different parts of the authentication and domain infrastructure. So when they disagree, the disagreement is often useful information rather than a sign that one of them is broken.

nltest /dsgetdc: which DC would DC Locator use?

Run:

cmd

nltest /dsgetdc:example.com

This exercises the domain controller locator process and returns a suitable DC for the specified domain. To bypass the client’s cached answer and force a fresh discovery against DNS, add /force:

cmd

nltest /dsgetdc:example.com /force

That’s the switch to use when you’re testing a change to sites, subnets, DNS or DC availability, because without it you may just be reading a cached answer from before the change. For example, %LOGONSERVER% might show \\Server-DC2 while a forced discovery returns:

text

DC: \\Server-DC3
Address: \\10.10.10.13
Dom Name: example.com
Forest Name: example.com
Dc Site Name: Brisbane
Our Site Name: Brisbane
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC CLOSE_SITE
The command completed successfully

That doesn’t automatically mean something is wrong. %LOGONSERVER% is telling you about the logon session, while nltest is performing DC discovery right now.

Two flags in that output are worth reading. CLOSE_SITE means the DC is in the same site as the client, which is what you want. WRITABLE distinguishes a normal DC from a read-only domain controller, which matters if you’re troubleshooting something that needs to write to the directory.

Two other switches worth knowing

nltest /dsgetdc:example.com /writable returns only a writable DC, which is useful in environments with RODCs at branch sites.

nltest /dsgetdc:example.com /try_next_closest_site looks for a DC in the client’s own site first and, failing that, in the next closest site. That’s how clients fail over when no DC is available locally, so it’s useful for validating what happens during a site outage.

gpresult: which DC actually applied Group Policy?

gpresult /r is especially valuable when troubleshooting a domain-joined computer, because it shows what Group Policy processing actually reported, rather than which DC the machine would choose now. Run it and you’ll see separate sections:

text

COMPUTER SETTINGS
------------------
    Applied Group Policy Objects
    ...

USER SETTINGS
-------------
    Applied Group Policy Objects
    ...

That separation matters, because computer policy and user policy can be applied from different logon servers. Check the USER SETTINGS section too, not just the computer section. That one detail explains a problem that otherwise looks inconsistent: computer policy working correctly while user policy isn’t applying, drive mappings are missing, a user-based GPO doesn’t appear, and the computer and user sections show different DC information.

For a detailed report, generate an HTML file and open it in a browser, then check both the computer and user sections:

cmd

gpresult /h C:\Temp\gpresult.html

klist: look at the Kerberos tickets

If you’re troubleshooting Kerberos authentication, klist shows the tickets currently held by the logon session. You’ll typically see tickets for services such as krbtgt/EXAMPLE.COM, cifs/server.example.com and HTTP/server.example.com. That tells you Kerberos is in use and shows which service tickets are present.

Don’t overinterpret it, though. klist isn’t a command that says “this is the domain controller that authenticated me”. It shows the Kerberos tickets in the current session, so use it alongside the other commands when investigating authentication behaviour.

nltest /sc_query: check the computer’s secure channel

For a domain-joined computer, run:

cmd

nltest /sc_query:example.com

text

Trusted DC Name \\Server-DC2.example.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

There’s an important detail here. Microsoft’s reference describes /sc_query as reporting the state of the secure channel the last time it was used, not as a live test, so a healthy-looking result doesn’t guarantee the channel works right now. To actually test it, or to rebuild it, use:

cmd

nltest /sc_verify:example.com
nltest /sc_reset:example.com

/sc_verify tests the channel, and /sc_reset forces a new secure channel, optionally to a DC you specify. This is the area to look at when you’re investigating domain trust errors, machine account problems, authentication failures, or computers that appear to be joined to the domain but can’t communicate with it properly. Again, this isn’t necessarily the same DC that handled a particular user’s interactive logon. It’s answering a different question.

When the answers don’t match

Suppose you get this:

text

%LOGONSERVER%       Server-DC2
nltest /dsgetdc     Server-DC3
secure channel      Server-DC2

When the answers don’t match like this, don’t assume Active Directory is broken. Ask what each result represents instead. %LOGONSERVER% tells you which DC was recorded at interactive logon. nltest /dsgetdc tells you which DC the locator can find now. The secure channel result tells you which DC the computer’s secure channel used when it was last exercised. Those can legitimately differ.

The same applies to Group Policy. If the computer and user sections show different processing information, that may be relevant to the problem you’re troubleshooting. The disagreement itself often gives you a direction for further investigation.

Check the computer’s Active Directory site

If your DCs are spread across offices, branches or data centres, the next thing to check is the client’s AD site:

cmd

nltest /dsgetsite

text

Brisbane
The command completed successfully

The site matters because Active Directory uses it when locating domain controllers, and the client works out its site from the IP subnet information in Active Directory Sites and Services. If the client’s subnet isn’t associated with the intended site, DC Locator can’t make the choice you expect. Clients then end up using a DC across a WAN, or in another location, when a local DC should have been preferred. A badly configured site topology quickly turns into slow logons and unexpected Group Policy traffic.

To check, go to Active Directory Sites and Services > Sites > Subnets, and make sure the client’s IP subnet exists and is linked to the correct site. A subnet that’s missing entirely is a frequent version of this problem. With no site, the client can’t use the site-specific DNS records. Microsoft’s DC Locator documentation notes that the client falls back to the domain’s general records, and a DC outside the client’s closest site will tell the client which site it actually belongs to.

DNS is part of DC discovery

Domain controller discovery depends heavily on DNS. DCs register SRV records that advertise services such as LDAP and Kerberos, and DC Locator queries DNS for those records to find available DCs, using site-specific records to prefer a local one. Microsoft’s guide to troubleshooting domain controller location issues walks through checking this end to end.

That’s why incorrect DNS configuration can cause what first looks like an authentication problem. A client might be using the wrong DNS servers, fail to locate the expected DC, discover a DC from another site, or give inconsistent results after a network change. Check the client’s DNS configuration first:

cmd

ipconfig /all

Then, if necessary, inspect the domain-wide SRV records and the site-specific records that DC Locator uses to prefer a local DC:

cmd

nslookup -type=SRV _ldap._tcp.dc._msdcs.example.com
nslookup -type=SRV _ldap._tcp.Brisbane._sites.dc._msdcs.example.com

If the site-specific record doesn’t exist, or returns a DC from somewhere else, that explains the client’s choice.

Checking a remote computer

The computer you’re troubleshooting often isn’t the one you’re sitting at. If PowerShell remoting is enabled, you can query the remote machine directly, and collect several values at once:

powershell

Invoke-Command -ComputerName PC01 -ScriptBlock {
    [PSCustomObject]@{
        ComputerName = $env:COMPUTERNAME
        LogonServer  = $env:LOGONSERVER
        Site         = (nltest /dsgetsite | Select-Object -First 1)
    }
}

The Select-Object -First 1 is deliberate. nltest /dsgetsite returns the site name followed by a completion message, so taking the first line keeps that message out of the Site property.

One caveat: $env:LOGONSERVER in a remote session reflects the account running the remote command, not necessarily the user sitting at the console. For the console user’s value, query it in their context or check the machine’s logon events. You can run the other checks remotely too:

powershell

Invoke-Command -ComputerName PC01 -ScriptBlock {
    nltest /dsgetdc:example.com /force
    nltest /sc_query:example.com
}

That’s usually far more productive than reading commands to a user over the phone.

Why a client picks a particular domain controller

Windows doesn’t pick an arbitrary DC. DC Locator uses the domain name, DNS records, the client’s site and the available domain controllers to select one, and Netlogon caches the result so the client keeps using a consistent DC rather than rediscovering for every operation. In simplified form:

1. The client determines its AD site from its IP subnet.
2. Netlogon calls DC Locator.
3. DNS is queried for the appropriate SRV records, site-specific ones first.
4. Available DCs are checked.
5. A suitable DC is selected.
6. The result is cached for later requests.

That caching is why /force matters when testing, and why a client can keep using an old DC for a while after a change. It’s also why Sites and Services matters so much in multi-office environments. If Brisbane, Sydney and Melbourne each have domain controllers, you want every client to know its site and use the local DC. If the subnet-to-site mapping is wrong, looking at %LOGONSERVER% alone won’t tell you why the client made the choice it did.

Common scenarios where the DC choice matters

Slow logons. If a workstation keeps using a DC across a WAN, check its AD site and subnet mapping before anything else. The DC choice is usually a symptom, not the cause, and fixing the subnet mapping is what brings the client back to a local DC.

Group Policy or user settings not applying. Run gpresult /r and check both COMPUTER SETTINGS and USER SETTINGS, because computer and user processing can involve different domain controllers. If drive mappings or other user configuration are missing, don’t take the computer’s successful processing as proof that everything is fine. Check the user section separately, and generate the HTML report if you need the detail.

Authentication failures. Compare %LOGONSERVER%, a forced DC Locator result, the secure channel and the Kerberos tickets. Where they disagree, that tells you whether you’re looking at a stale logon value, current DC discovery, a machine trust problem, or something specific to the user’s authentication session.

Users working remotely. A laptop that was last on the corporate network can still show a cached logon server even when it currently has no working path to any domain controller. That’s why %LOGONSERVER% should never be treated as proof that the computer can reach that DC right now.

After deploying a new DC. A successful promotion isn’t the same as clients using the new DC. Run nltest /dsgetdc:example.com /force from a client in the relevant site, and if the new DC doesn’t appear, check its SRV records and the site it was placed in.

Commands at a glance

There isn’t always one answer

There isn’t always a single answer to “which DC am I using?” There’s the DC associated with the logon session, the DC that DC Locator would select now, the DC behind the secure channel, the DCs involved in Group Policy processing, and the Kerberos infrastructure represented by the tickets in the session. Once you understand what each command is actually measuring, the differences stop being confusing and become useful troubleshooting information.

Logon server troubleshooting checklist

1. Run echo %LOGONSERVER% for the quick answer, remembering it reflects the interactive logon, not a live query.
2. Open an elevated prompt and run nltest /dsgetsite to confirm the client’s AD site.
3. Run nltest /dsgetdc:yourdomain /force to see which DC the locator chooses now, and check for the CLOSE_SITE and WRITABLE flags.
4. Run nltest /sc_query:yourdomain, and nltest /sc_verify:yourdomain if you need a live test of the secure channel.
5. Run gpresult /r and check both the COMPUTER SETTINGS and USER SETTINGS sections.
6. Run klist if the problem involves Kerberos authentication.
7. If the client is using a remote DC, check its subnet exists and is linked to the right site in Active Directory Sites and Services.
8. Check ipconfig /all and the domain-wide and site-specific SRV records with nslookup.
9. For a remote machine, collect the same values with Invoke-Command, keeping in mind that $env:LOGONSERVER reflects the remote session’s account.
10. After any change to sites, subnets or DNS, re-test with /force so you’re not reading a cached result.

Microsoft references

• Troubleshoot domain controller location issues in Windows – the DC Locator process, DNS SRV records and site selection
• Nltest command reference – the full switch list, including /dsgetdc, /sc_query, /sc_verify and /sc_reset

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.