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

If you manage an Active Directory environment with multiple domain controllers, sooner or later you’ll need to answer a simple question:

Which domain controller is this computer actually using?

The quickest answer is:

echo %LOGONSERVER%

For example:

\\Server-DC2

That tells you the domain controller recorded for the interactive logon session.

But there is an important catch: it is not 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 different commands below answer different questions, and that is why they can legitimately return different domain controllers.

The short answer: %LOGONSERVER%

From Command Prompt:

echo %LOGONSERVER%

Or:

set logonserver

set l also works, but I wouldn’t use it in a troubleshooting guide. It searches for environment variables beginning with L, so set logonserver is much more explicit.

From PowerShell:

$env:LOGONSERVER

%LOGONSERVER% is the domain controller associated with the interactive logon. It is an environment variable populated during logon.

That means it can become stale.

If a user logged on at 8:00 AM and FP-DC2 was their logon server, %LOGONSERVER% can still show FP-DC2 hours later even if the client is now using another domain controller for subsequent operations.

It also doesn’t prove that the machine contacted a domain controller during the current logon. Windows can use cached domain credentials when a domain controller isn’t available.

So %LOGONSERVER% is useful, but it is only one piece of the picture.

Before you start: nltest needs an elevated prompt

Most of the commands below use nltest, and it needs to be run from an elevated Command Prompt.

On a workstation, nltest is part of the Remote Server Administration Tools. If it isn’t present, install the AD DS tools feature or run the checks from a machine that has RSAT installed.

Why the commands can disagree

This is where Active Directory troubleshooting gets interesting.

Consider these five commands:

These aren’t five different ways of asking exactly the same question.

They are looking at different parts of the authentication and domain infrastructure.

That means when they disagree, the disagreement can be useful information rather than evidence that one of the commands is broken.

nltest /dsgetdc: Which DC would DC Locator use?

Run:

nltest /dsgetdc:example.com

This exercises the domain controller locator process and returns information about a suitable DC for the specified domain.

You can clear the client’s cached result and force a fresh discovery with:

nltest /dsgetdc:example.com /force

That’s the switch to reach for when you’re testing a change to sites, subnets, DNS or DC availability, because without it you may simply be reading a cached answer from before the change.

For example:

echo %LOGONSERVER%
\\Server-DC2

but:

nltest /dsgetdc:example.com /force

might return:

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.

The first command is telling you about the logon session.

The second is performing DC discovery 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

Tests the next-closest-site behaviour, which is how clients fail over when no DC is available in their own site. Useful when you’re validating what happens during a site outage.

gpresult: Which DC actually applied Group Policy?

This is one of the most useful commands when troubleshooting a domain-joined computer.

Run:

gpresult /r

You’ll see separate sections for:

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

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

This matters because the computer settings policy and the user settings policy can be applied from different logon servers, so make sure you check the user settings section also.

That one detail explains a problem that otherwise looks inconsistent.

For example, you might have:

• computer policy working correctly
• user policy not applying
• drive mappings missing
• a user-based GPO not appearing
• different DC information associated with the computer and user processing

Don’t just check the computer section and assume you’ve found the answer.

gpresult is particularly useful because you’re looking at what Group Policy processing actually reported, rather than simply asking which DC the machine would choose now.

You can generate a detailed HTML report with:

gpresult /h C:\Temp\gpresult.html

Open the resulting file in a browser and inspect both the computer and user sections.

klist: Look at the Kerberos tickets

If you’re troubleshooting Kerberos authentication, klist shows the tickets currently held by the logon session:

klist

You’ll typically see tickets for services such as:

krbtgt/EXAMPLE.COM
cifs/server.example.com
HTTP/server.example.com

This can tell you that Kerberos is being used and show the service tickets currently present.

It is important not to overinterpret this command, though.

klist isn’t simply a command that says “this is the domain controller that authenticated me”. It is showing the Kerberos tickets in the current session.

Use it alongside the other commands when you’re investigating authentication behaviour.

nltest /sc_query: Check the computer’s secure channel

For a domain-joined computer, run:

nltest /sc_query:example.com

For example:

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

One important detail about this command: Microsoft documents it 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.

If you need to actually test and rebuild the channel:

nltest /sc_verify:example.com

nltest /sc_reset:example.com

/sc_verify tests the channel. /sc_reset forces a new secure channel, optionally to a specified DC.

This area is particularly useful when you’re investigating:

• domain trust errors
• machine account problems
• authentication failures
• computers that appear to be joined to the domain but can’t communicate correctly with it

Again, this isn’t necessarily the same DC that handled a particular user’s interactive logon.

It is answering another question.

When the answers don’t match

Suppose you get:

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

Don’t immediately assume you have a broken Active Directory environment.

Instead, ask what each result represents.

%LOGONSERVER% tells you which DC was recorded at interactive logon.

nltest /dsgetdc tells you which DC Locator can find now.

The secure-channel result tells you which DC was used for the computer’s secure channel when it was last exercised.

Those can legitimately differ.

The same applies to Group Policy. If the computer settings and user settings show different processing information, that can be relevant to the problem you’re troubleshooting.

The disagreement itself can give you a direction for further investigation.

Check the computer’s Active Directory site

If DCs are spread across offices, branches or data centres, the next thing I would check is the client’s AD site.

Run:

nltest /dsgetsite

For example:

Brisbane
The command completed successfully

The site is important because Active Directory uses site information when locating domain controllers.

The client determines its site from the IP subnet information configured in Active Directory Sites and Services.

If the client’s subnet isn’t correctly associated with the intended site, DC Locator cannot make the site selection you expect.

That can result in clients using a DC across a WAN or from another location when a local DC should have been preferred.

This is one of the reasons a badly configured AD site topology turns into slow logons and unexpected Group Policy traffic.

If you’re investigating this, check:

Active Directory Sites and Services → Sites → Subnets

Make sure the client’s IP subnet exists and is associated with the correct site.

A subnet that doesn’t exist at all is the most common version of this problem. The client has no site, so DC Locator has no site preference to work with.

DNS is part of DC discovery

Domain controller discovery also depends heavily on DNS.

Domain controllers register SRV records that advertise services such as LDAP and Kerberos. DC Locator queries DNS for those records and uses the results to identify available DCs. Microsoft’s documentation on how domain controllers are located describes the process in detail, including the site-specific records used to prefer a local DC.

This is why incorrect DNS configuration can cause what initially looks like an authentication problem.

For example, a client might:

• resolve the wrong DNS servers
• fail to locate the expected DC
• discover a DC from another site
• have inconsistent results after network changes

Check the client’s DNS configuration first:

ipconfig /all

Then, if necessary, inspect the SRV records themselves:

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

And the site-specific records, which are what DC Locator uses to prefer a local DC:

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

A lot of the time, the computer you’re troubleshooting isn’t the computer you’re sitting at.

If PowerShell remoting is enabled, you can query the remote machine directly:

Invoke-Command -ComputerName PC01 -ScriptBlock {
    $env:LOGONSERVER
}

You can also collect several useful values at once:

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 intentional. nltest /dsgetsite returns the site name followed by its command-completion message, so taking the first line keeps the completion text out of the Site property.

One caveat worth knowing: $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 own logon events.

You can run the other checks remotely as well:

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

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

Why a client picks a particular domain controller

Windows doesn’t simply pick an arbitrary DC.

DC Locator uses the domain name, DNS records, the client’s site and the available domain controllers when selecting one. Netlogon then caches the result so the client keeps using a consistent DC rather than rediscovering for every operation.

The simplified process is:

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 subsequent 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 also makes AD Sites and Services particularly important in environments with multiple offices. If Brisbane, Sydney and Melbourne each have domain controllers, you want each client to know which site it belongs to and use the appropriate local DC.

If the subnet-to-site mapping is wrong, troubleshooting %LOGONSERVER% alone won’t tell you why the client made that choice.

A practical troubleshooting sequence

When someone asks:

“Which domain controller am I authenticated to?”

Start with:

echo %LOGONSERVER%

Then, if the answer matters because you’re troubleshooting something, work outward from an elevated prompt:

nltest /dsgetsite
nltest /dsgetdc:example.com /force
nltest /sc_query:example.com
gpresult /r
klist

You’re now looking at several different parts of the authentication process rather than relying on one environment variable.

When this matters

Slow logons

If a workstation is repeatedly using a DC across a WAN, check its AD site and subnet mapping first. The DC choice is usually a symptom, not the cause.

Group Policy not applying

Run gpresult /r and check both COMPUTER SETTINGS and USER SETTINGS.

Remember that the computer and user policy processing can involve different domain controllers.

Drive mappings or user configuration missing

If the user’s policy isn’t being applied, don’t assume the computer’s successful Group Policy processing means everything is fine.

Check the user section separately.

Authentication failures

Compare %LOGONSERVER%, DC Locator, the secure channel and Kerberos information.

A disagreement can help identify whether you’re looking at a stale logon value, current DC discovery, a machine trust problem or something involving the user’s authentication session.

Users working remotely

A laptop that was previously on the corporate network may have a cached logon value even when it currently has no working path to a domain controller.

That is why %LOGONSERVER% should never be treated as proof that the computer can currently communicate with that DC.

After deploying a new DC

Promotion succeeding isn’t the same as clients using it. From a client in the relevant site:

nltest /dsgetdc:example.com /force

If the new DC doesn’t appear, check its SRV records and the site it’s been placed in.

Commands at a glance

The useful lesson

There isn’t always one single answer to “which DC am I using?”

There is the DC associated with the logon session, the DC that DC Locator would select now, the DC involved in 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.

They become useful troubleshooting information.

Microsoft references

• How domain controllers are located 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.