Author |
Topic: NLTEST utility (Read 131 times) |
|
Windows Server Util
Guest
|
 |
NLTEST utility
« Thread started on: Jul 21st, 2004, 12:04pm » |
|
Microsoft Windows NT Server Resource Kit and Microsoft Windows NT Workstation Resource Kit include a tool, nltest.exe, that lets you quickly test the status of the NetLogon linkages between machines. This utility usually can't repair trust relationships, but because NLTEST is a command-line tool, you can incorporate it into batch files to automatically monitor machine connections.
To test a machine's link to its domain, you use NLTEST's /query option, which verifies that NetLogon is running. For example, if you have an NT server (or NT workstation) named MINBAR and want to see if NetLogon is running and functioning properly on that machine, open a command line and type
nltest /server:minbar /query
You'll see a few messages and finally the Command completed successfully message.
Each active domain member should have a functioning secure channel to a domain controller. To check that status, you use the /sc_query option. If MINBAR is a member of a domain named B5, you test its domain connection with
nltest /server:minbar /sc_query:B5
The command responds with success or failure, and provides the name of the domain controller that MINBAR has a secure channel to. If the command reports a problem, you can replace /sc_query with /sc_reset to try to reset the secure connection. The /sc_reset option might also work to reset a broken trust relationship.
NetLogon also governs PDC-BDC communications. You can find out what machines are domain controllers on a domain with the /dclist option. For the B5 domain example, you can list the domain controllers with
nltest /dclist:b5
You can get the name of the PDC with /dcname.
You can control PDC-BDC SAM replications with the /repl option or resynchronize the entire SAM database with the /sync option. For example, if you have a BDC named AJAX, you can force that BDC to dump its copy of the domain's SAM and request a new one from the domain's PDC with
nltest /server:ajax /sync
To tell the BDC to request the changes to the SAM since the last replication, replace /sync with /repl. If that domain has a PDC named XERXES, you can initiate the process from the PDC's side with
nltest /server:xerxes /pdc_repl
Domain-domain trust relationships get a little tricky. The /trusted_domains option shows you what domains are trusted by the domain that your machine is in. Suppose you have a two-domain enterprise with domains MASTER and RESOURCE. All the user accounts are in MASTER, and all the NT machines are members of domain RESOURCE. You've established a trust relationship so that RESOURCE trusts MASTER. You're logged on to a machine with your user account, which lives in domain MASTER, and the machine you're logged on to is a member of domain RESOURCE. If you run
nltest /trusted_domains
you'll be told that MASTER is trusted. The fact that you're logged on as a member of MASTER is irrelevant. The message means that RESOURCE, the machine's domain, trusts MASTER. If you logged on to the domain controller at MASTER and ran the same command, you'd get a blank list.
NLTEST lets you determine whether you can establish a NetLogon session with a particular machine. If NetLogon is up, you can use the /sc_query option to test connections to a domain controller and the /sc_reset option to try to repair a link. The remaining options let you examine a machine's link to its domain, PDC-BDC connections, and trust relationships.
|
|
 Logged
|
|
|
|
|
