nltest is a command-line utility that communicates directly with the Netlogon service on Windows. It gives system administrators direct access to domain controller discovery, trust relationship inspection, and secure channel management — all from the command line, without opening Active Directory tools or the GUI. This article covers the practical scenarios where nltest saves time: from finding the DC your machine is talking to, to diagnosing and repairing broken domain trust.
Quick Answer
Check which domain controller your machine is currently using:
nltest /dsgetdc:corp.localReplace corp.local with your actual domain name. The output shows the DC name, IP address, site, and flags such as GC, KDC, and WRITABLE.
What nltest does
nltest (NetLogon Test) is a command-line utility built into Windows that communicates directly with the Netlogon service. It lets you query domain controller information, inspect trust relationships, and test or repair the secure channel between a computer and its domain — all without touching Group Policy or the GUI.
Basic syntax:
nltest /option[:value]nltest is available on Windows Server by default and on Windows 10/11 workstations with RSAT (Remote Server Administration Tools) installed. Some flags — particularly /sc_reset — require local administrator rights or Domain Admin privileges.
Practical Examples
1. Find the domain controller your machine is using
The problem: A workstation is behaving oddly during logon — slow authentication, GPO not applying, or group membership not resolving correctly. You need to know which DC the machine is talking to before you can investigate further.
The solution: nltest /dsgetdc queries the Netlogon service and returns the DC currently used for authentication, along with its IP, site, and capabilities.
nltest /dsgetdc:corp.localExpected output:
DC: \\DC01.corp.local
Address: \\192.168.1.10
Dom Guid: 3f6a1b2c-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Dom Name: corp.local
Forest Name: corp.local
DC Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
The command completed successfullyFlags field tells you a lot at a glance. GC means it is a Global Catalog server. WRITABLE confirms it is not a read-only DC. KDC confirms Kerberos is active on this controller.
2. List all domain controllers in the domain
The problem: You are troubleshooting a replication issue or planning maintenance and need a quick list of all DCs in the domain without opening Active Directory Users and Computers.
The solution: nltest /dclist queries the domain and returns all known domain controllers along with their roles.
nltest /dclist:corp.localExpected output:
List of DCs in domain corp.local
\\DC01.corp.local [PDC] [DS] Site: Default-First-Site-Name
\\DC02.corp.local [DS] Site: Branch-Site
The command completed successfully3. Force DC rediscovery
The problem: A workstation has cached a reference to a DC that was decommissioned or is temporarily unreachable. Authentication is slow or failing, but the machine refuses to switch to a healthy DC on its own.
The solution: The /force flag bypasses the cached DC entry and forces the Netlogon service to rediscover the best available DC.
nltest /dsgetdc:corp.local /force4. Find the PDC Emulator
The problem: You need to identify the PDC Emulator in the domain — for example, to check time synchronization, investigate password change replication delays, or target a specific DC for an AD operation.
The solution: nltest /dcname returns the name of the PDC Emulator FSMO role holder for the specified domain.
nltest /dcname:corp.localExpected output:
PDC for Domain corp.local is \\DC01
The command completed successfully5. Check domain trust relationships
The problem: Users in a partner domain cannot access resources, or authentication across a forest trust is failing. Before investigating further, you need a clear picture of what trusts exist and in which direction.
The solution: nltest /domain_trusts lists all trust relationships visible from the current machine, including direction, type, and status flags.
nltest /domain_trustsExpected output:
List of domain trusts:
0: corp.local (NT 5) (Direct Outbound) ( Attr: 0x20 ) (MIT) S-1-5-21-...
1: partner.local (NT 5) (Forest: 2) (Direct Inbound) ( Attr: 0x8 )
The command completed successfullyDirect Outbound means your domain trusts the other domain — users from that domain can authenticate here. Direct Inbound means the other domain trusts yours. A bidirectional trust shows both.
6. Test the secure channel
The problem: A workstation is throwing the “trust relationship between this workstation and the primary domain failed” error, but you are not sure whether the secure channel is actually broken or the issue is elsewhere.
The solution: nltest /sc_verify actively tests the secure channel to the domain and reports whether it is intact, which DC it is using, and whether the channel can be used for authentication.
nltest /sc_verify:corp.localExpected output when the channel is healthy:
Flags: b0 HAS_IP HAS_TIMESERV
Trusted DC Name \\DC01.corp.local
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfullyNERR_Success on both lines confirms the secure channel is intact. If you see a non-zero status code instead, the channel is broken and needs to be reset.
7. Reset the secure channel
The problem: The secure channel is confirmed broken. The standard fix is to unjoin and rejoin the domain, but that takes time and requires a reboot. You need a faster option — especially if the machine is a server you cannot afford to disconnect.
The solution: nltest /sc_reset resets the secure channel from the command line by negotiating a new session with the domain. Run it with administrator privileges.
nltest /sc_reset:corp.local/sc_reset does not always fix a deeply broken secure channel. If the computer account password has expired or the account has been disabled in AD, the channel reset will fail and you will need to unjoin and rejoin the domain — or use Reset-ComputerMachinePassword in PowerShell as Domain Admin.
8. Check which AD site a domain controller belongs to
The problem: You have a multi-site AD environment and need to verify that a specific DC is associated with the correct site — for example, after adding a new subnet or moving a DC between physical locations.
The solution: Use the /server flag combined with /dsgetsite to query a specific DC for its site assignment.
nltest /server:DC02 /dsgetsiteExpected output:
Branch-Site
The command completed successfullynltest /dsgetdc:corp.local and reading the DC Site Name field from the output.
9. Verify the domain hierarchy and forest structure
The problem: You are working in a multi-domain forest and need to quickly confirm the parent domain of a child domain — for example, when troubleshooting cross-domain authentication or planning a migration.
The solution: nltest /parentdomain returns the parent domain of the domain the current machine belongs to. For forest root DCs, combine it with /domain_trusts to see the full trust hierarchy.
nltest /parentdomainExpected output on a child domain member:
ParentDomain: corp.local
The command completed successfullyTo get a broader view of the forest structure from any domain member:
nltest /domain_trusts /all_trusts/all_trusts extends the output to include indirect trusts and transitive relationships across the forest, not just direct trusts visible from the current domain.
Quick reference
| Use case | Command |
|---|---|
| Get current DC | nltest /dsgetdc:domain.com |
| Force DC rediscovery | nltest /dsgetdc:domain.com /force |
| List all DCs | nltest /dclist:domain.com |
| Find PDC Emulator | nltest /dcname:domain.com |
| Check trust relationships | nltest /domain_trusts |
| Test secure channel | nltest /sc_verify:domain.com |
| Reset secure channel | nltest /sc_reset:domain.com |
| Check DC site assignment | nltest /server:DC02 /dsgetsite |
| Find parent domain | nltest /parentdomain |
| Full forest trust view | nltest /domain_trusts /all_trusts |
Hidden gems
Target a specific DC remotely
Almost every nltest flag supports the /server:<name> prefix, which lets you run the query against a specific DC rather than the one your machine is currently using. This is useful when you need to compare the view from two different controllers — for example, checking whether a trust is visible on both DC01 and DC02 during a replication investigation.
nltest /server:DC02 /domain_trustsFind the nearest DC in a specific site
When you need to force DC discovery within a specific AD site — for example, to verify that a new DC in a remote office is reachable and correctly responding — use the /site flag.
nltest /dsgetdc:corp.local /site:Branch-SiteFind the nearest Global Catalog server
If applications or Exchange are struggling with universal group resolution or cross-domain lookups, identifying the nearest GC is the first diagnostic step. The /gc flag restricts DC discovery to Global Catalog servers only.
nltest /dsgetdc:corp.local /gcCheck logon attempt statistics
nltest /logon_query returns cumulative logon attempt counts from the Netlogon service since the last restart. This is not a security log, but it is a fast way to confirm that Netlogon is processing authentication requests — useful when diagnosing whether a machine is actually communicating with the domain at all.
nltest /logon_query/logon_query reset on every Netlogon service restart, including after a reboot. Do not use these numbers as a long-term audit source.
PowerShell equivalents
If nltest is not available — for example, on a machine without RSAT — the following PowerShell commands cover the most common operations.
Find the current domain controller:
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().FindDomainController().NameList all domain controllers:
Get-ADDomainController -Filter * | Select-Object Name, Site, IsGlobalCatalogTest and repair the secure channel:
Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)Find trust relationships:
Get-ADTrust -Filter * | Select-Object Name, Direction, TrustTypeGet-ADDomainController and Get-ADTrust require the ActiveDirectory PowerShell module (part of RSAT). Test-ComputerSecureChannel -Repair requires Domain Admin credentials to reset the computer account password in AD.
Where this matters
Broken domain trust on a production server — when a server throws the trust relationship error, nltest /sc_verify confirms whether the channel is actually broken before you commit to a full unjoin/rejoin procedure.
Post-migration DC validation — after promoting a new DC or decommissioning an old one, nltest /dclist and nltest /dcname give a fast confirmation that the domain sees the correct controllers and that FSMO roles are in the expected place.
Multi-site AD environments — when a machine in a remote office authenticates against a DC in headquarters instead of the local site, nltest /dsgetdc /force combined with /site helps you verify whether site-aware DC discovery is working correctly.
Cross-domain authentication failures — when users from a trusted domain cannot access resources, nltest /domain_trusts is the fastest way to confirm that the trust is present and in the correct direction before escalating to a full AD diagnostic.
Scripted environment checks — nltest output is plain text and parses cleanly with findstr, making it suitable for batch scripts that perform domain health checks across multiple machines.
Tips and limitations
A few things worth knowing before you rely on nltest in production:
/sc_resetand/sc_verifyrequire local administrator rights. Running them from a standard user account will return an access denied error.nltestis available on Windows Server by default. On Windows 10/11 workstations, it requires RSAT to be installed. On some minimal Server Core installations it may be absent.- nltest queries the local Netlogon service. If the Netlogon service is stopped, most commands will fail or return incomplete results.
- The tool does not support JSON or structured output. For automation and scripting at scale, PowerShell cmdlets from the ActiveDirectory module are a better choice.
nltest /sc_reset and assuming the trust is fixed because the command returned success. The reset only re-establishes the secure channel session — it does not fix an expired or disabled computer account in Active Directory. Always follow up with /sc_verify to confirm the channel is actually working.
Official reference
nltest — Windows Commands | Microsoft Learn
Related guides
How to fix “trust relationship between this workstation and the primary domain failed”